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1  Foreword 


The  final  report  summarizes  the  research  results  obtained  imder  ARO / CECOM  contract  No.  DAAL03- 
91’G-0093.  The  research  covered  five  areas  in  protocol  engineering  and  distributed  systems:  protocol 
conversion,  conformance  testing,  multimedia  protocols,  high  speed  packet  switches  and  distributed 
control.  A  total  of  28  publications  have  been  credited  to  the  contract,  including  4  Ph.  D.  disserta¬ 
tions,  6  journal  publications  and  18  publications  in  international  conference  proceedings.  Included 
in  the  appendices  are  six  reprints  of  publications  that  were  not  included  in  two  previous  progress 
reports. 

The  research  group  should  like  to  thank  Drs.  William  A.  Sander  (ARO)  and  Charles  J.  Graft 
(CECOM)  for  their  support  and  leadership  to  make  the  research  both  worthwhile  and  rewarding. 
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4.  Appendices 
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Proc.  7th  IFIP  Inti  Workshop  on  Protocol  Test  Systems,  pp.  149-164,  November  1994. 
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2  Report  Body 


In  this  section,  the  research  results  are  presented.  The  research  covered  five  areas:  protocol  conver¬ 
sion,  conformance  testing,  multimedia  protocols,  high-speed  packet  switches  and  distributed  control. 
The  problems  that  were  investigated  in  the  respective  areas  are  first  described  in  Section  2.1,  then 
the  major  results  of  the  research  are  summarized  in  Section  2.2.  A  list  of  publication  credited  to  this 
grant  and  the  participating  personnel  can  be  found  in  Section  2.3  and  Section  2.4,  respectively. 


2.1  Statement  of  Problems 


2.1.1  Protocol  Conversion 


Due  to  the  competitive  and  proprietary  nature  of  computer  networking  and  the  rapid  advances  in 
computers  and  communications,  many  diverse  network  architectures  and  communication  protocols 
have  been  developed  during  the  past  two  decades.  As  a  result,  it  poses  problems  for  various  networks 
to  communicate  with  one  another.  To  provide  interoperability  for  systems  residing  on  two  networks 
that  employ  different  protocols,  some  special  devices,  called  gateways  or  converters,  are  needed 
to  ensure  that  the  transition  sequences  of  one  protocol  are  correctly  converted  to  the  transition 
sequences  of  the  other  protocol.  Currently,  most  of  the  protocol  converters  are  constructed  in  an  ad 
hoc  manners  [29,  30,  31,  32].  However,  both  economic  and  technical  consideration  demand  simpler 
and  more  reliable  converters,  which  ad  hoc  converters  cannot  provide.  To  achieve  the  goal,  formal 
methods  for  protocol  conversion  are  needed.  The  objective  of  the  research  is  to  develop  formal 
methods  for  constructing  protocol  converters  so  that  the  converters  are  free  of  deadlock,  unexpected 
reception,  improper  termination  and  channel  overflow. 


2.1.2  Conformance  Testing 


When  a  formal  Description  Technique  (FDT)  is  used  to  formally  specify  a  communication  protocol, 
and  if  the  corresponding  tr2mslator  of  the  FDT  can  generate  the  error-free  machine  executable  code 
for  the  protocol,  then  protocol  testing  is  no  longer  required.  Unfortimately,  an  implementation  of  the 
protocol  always  consists  of  two  parts,  the  machine  independent  part  and  the  machine- dependent  part. 
Although  the  machine-independent  part  can  be  mechanically  translated  into  machine  executable 
code,  the  machine-dependent  part  must  be  manually  encoded  by  protocol  implementors.  As  a  result, 
errors  may  be  introduced  into  the  implementation.  Conformance  testing  is  thus  needed  to  make  sure 
that  the  implementation  conforms  to  its  specification.  For  conducting  conformance  testing,  a  set  of 
test  sequences,  called  a  test  suite,  must  be  generated.  Our  research  objectives  £tre  (1)  to  develop  a 
test  architecture  that  integrates  design  and  testing  process  into  a  single  development  environment 
so  that  the  generation  of  test  sequences  can  be  facilitated,  and  (2)  to  develop  procedures  that  can 
generate  test  sequences  from  the  protocol  specification. 
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2.1.3  Multimedia  Protocols 


To  meJce  multimedia  applications  a  reality  in  the  near  future,  two  important  problems  need  to  be 
solved  first:  how  to  provide  timely  transmission  of  multimedia  data  over  networks,  specifically,  local 
area  networks  and  how  to  present  multimedia  data  as  a  whole  to  end  users.  Traditional  local  area 
networks  are  not  quite  suitable  for  trEinsmission  of  multimedia  data.  Multimedia  data  integrate  video, 
voice,  image  and  text,  which  may  have  stringent  delay  requirement.  However,  traditional  local  area 
networks  are  designed  to  handle  regular  data  which  are  bursty  in  nature  but  allow  variable  delay.  If 
multimedia  data  are  transmitted  in  local  area  networks  using  existing  protocols,  the  time-critical  data 
wiU  have  to  compete  with  regulcir  data  and  wiU  suffer  intolerable  delay.  In  addition,  even  if  timely 
transmission  of  multimedia  data  can  be  provided,  there  is  another  problem  of  media  synchronization. 
Since  different  kinds  of  multimedia  data,  such  as  video  and  voice,  have  different  characteristics  and 
requirements,  they  must  be  transmitted  through  networks  in  several  media  streams.  These  data, 
however,  must  be  presented  as  a  whole  to  end  users  at  receiving  ends.  Since  these  different  media 
streams  may  experience  different  network  jitter  and  data  loss  during  transmission,  schemes  are  needed 
to  resolve  the  problems  in  order  to  achieve  synchronous  presentation  of  data  in  various  multimedia 
strecims  at  the  destinations. 


2.1.4  High-Speed  Packet  Switches 


The  recent  rapid  development  in  integrated  broadband  networks  has  been  driven  by  the  push  from 
new  applications  and  the  pull  from  the  advance  of  new  technologies.  To  realize  integrated  broadband 
networks,  new  switching  technologies  to  support  a  variety  of  communication  services  with  a  wide 
range  of  data  rates  are  essential.  Mainly  due  to  its  flexibility,  fast  packet  switching  has  emerged  as 
the  most  appropriate  switching  techniques  for  integrated  broadband  networks.  One  great  challenge 
is  the  design  of  packet  switching  fabrics  that  can  switch  packets  at  speeds  several  orders  of  magnitude 
higher  than  that  of  the  current  packet  switches.  Although  there  is  no  general  consensus  of  what  the 
switching  fabrics  for  the  future  networks  should  be,  most  of  the  recent  proposals  in  the  literature 
have  been  based  on  a  switching  principle  that  employs  (a)  high  degree  of  parallelism  (b)  distributed 
control,  and  (c)  hardwired  routing.  However,  to  be  deployed  on  a  large  scale,  switching  fabrics  should 
also  be  faiilt-tolerant  and  congestion-free,  in  addition  to  the  three  requirements  mentioned  above. 
Our  first  objective  in  this  research  is  to  propose  new  high-speed  switching  fabrics  that  can  satisfy 
the  above  requirements.  In  addition,  the  existing  analytical  models  is  not  adequate  to  evaluate  the 
performance  of  high-speed  switching  fabrics  tmder  nonuniform  traiffic  patterns.  Our  second  objective 
in  this  research  is  to  address  the  formrilation,  mathematicad  modeling,  and  performance  evaluation 
for  high-speed  switching  fabrics. 


2.1.5  Distributed  Control 


In  this  area,  our  research  focuses  on  two  topics.  The  first  topic  is  related  to  distributed  rule  moni¬ 
toring  in  distributed  active  databases.  Production  rules  provide  an  unifying  mechanism  for  several 
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traditional  features  in  database  management  systems  and  for  new  functionalities  sought  after  by 
potential  database  applications.  With  integrated  production  rules,  a  database  is  transformed  from 
traditionally  passive  to  active  such  that  the  database  will  take  predefined  actions  without  user  inter¬ 
vention  when  the  database  moves  into  certain  states.  Processing  every  ride  upon  every  update  in  the 
system  places  a  tremendous  performance  requirement  on  the  success  of  active  databases.  However, 
the  availability  of  multiple  sites  in  a  distributed  database  offers  an  opportunity  to  process  rules  in 
paraUel.  In  addition,  the  features  offered  by  production  rules  are  desirable  to  distributed  databases 
as  well.  The  main  objective  of  this  research  is  to  investigate  the  problem  of  monitoring  rules  in  a 
distributed  active  database  such  that  rules  can  be  successfully  integrated  into  distributed  databases. 

The  other  topic  is  related  to  the  scheduling  policies  of  distributed  operating  systems.  Recently, 
workstation-based  distributed  systems  have  increasingly  replaced  large,  multiuser,  stand-alone  com¬ 
puters.  Distributed  scheduling  can  be  used  to  coordinate  several  inexpensive  workstations  so  that 
their  combined  computing  power  is  able  to  compete  with  that  of  an  expensive  centralized  computer. 
When  a  scheduler  finds  that  a  remote  processor  is  a  better  execution  site  for  some  jobs  than  the  local 
processor,  it  transfers  the  job  to  the  remote  processor.  While  transferring  jobs  from  overloaded  to 
underloaded  nodes  in  a  distributed  system  can  potentially  improve  performance,  the  characteristics 
of  job  vajy  enormously,  and  not  all  jobs  are  equally  advantageous  to  transfer.  To  maximize  perfor¬ 
mance,  the  jobs  to  be  transferred  must  be  selected  carefully.  Thus,  a  good  selection  policy  is  very 
important.  However,  little  research  has  addressed  this  issue.  Devising  such  a  policy  is  particularly 
challenging  because  deciding  the  suitability  of  transferring  a  job  implies  predicting  the  resource  re¬ 
quirements  of  the  job  before  it  is  actually  executed,  which  is  a  very  difficult  task.  Our  objective  in 
this  direction  is  to  propose  an  intelligent  job  selection  policy  that  can  takes  both  the  characteristics 
of  the  job  and  the  current  system  environment  into  account,  and  that  can  adapt  to  changing  job 
characteristics  and  environments. 


2.2  Summary  of  Results 
2.2.1  Protocol  Conversion 

Our  contribution  to  this  peurt  of  the  research  can  be  classified  into  the  conversion  specification  ap¬ 
proach  and  the  service  specification  approach.  The  former  uses  conversion  specifications  which 
describe  the  mapping  of  transition  sequences  between  two  protocols  and  the  latter  uses  service  spec¬ 
ifications  which  describe  the  required  services  offered  by  the  final  composite  protocol. 

For  the  conversion  specification  approach,  two  transformation  procedures  [1]  are  proposed  that 
transform  the  protocol  conversion  problem  into  either  the  protocol  validation  problem  or  the  protocol 
synthesis  problem,  depending  on  whether  a  gateway  converter  or  an  end-node  converter  is  needed. 
Then,  the  existing  protocol  synthesis  algorithms  and  validation  algorithms  can  be  used  to  construct 
a  protocol  converter  for  a  given  conversion  specification.  By  transforming  a  protocol  conversion 
problem  into  a  protocol  validation  or  a  synthesis  problem,  the  method  proposed  can  take  advantage 
of  the  transformation  and  use  existing  protocol  validation  or  synthesis  algorithms  to  construct  a 
protocol  converter. 
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For  the  service  specification  approach,  two  algorithms  [16,  9]  are  proposed  to  formally  derive 
a  protocol  converter  from  its  service  specification.  The  existing  methods  in  the  literature  [33,  34] 
consider  only  the  safety  property  in  deriving  protocol  converters  from  service  specification.  As  a 
result,  they  only  guarantee  that  a  subset  of  the  required  services  is  provided  by  the  final  composite 
protocol.  Consequently,  an  extra  phase  is  needed  to  verify  that  the  final  protocol  can  indeed  support 
the  whole  service  specification.  The  work  proposed  by  us  in  [16]  suggests  the  use  of  the  system  graph 
to  construct  protocol  converters  such  that  the  system  graph  can  be  used  not  only  to  derive  a  protocol 
converter,  but  also  to  verify  against  the  required  service  specification.  Furthermore,  a  more  elegant 
solution,  called  Synchronization  Transition  Set  approach  [9],  is  later  on  proposed.  This  solution  is 
motivated  by  our  observation  that  the  main  problems  of  the  existing  methods  are,  indeed,  due  to  the 
fact  that  the  information  of  the  protocol  implementation  was  not  taken  into  consideration  during  the 
converter  construction  process.  For  a  given  service  specification,  there  may  be  a  number  of  different 
implementations  for  a  protocol,  and  since  the  goal  of  protocol  conversion  is  to  find  a  correct  converter 
for  the  existing  protocol  implementation,  the  information  on  the  existing  protocol  specification  must 
be  taken  into  consideration  for  the  conversion  to  be  correct.  Based  on  this  observation,  a  5-step 
protocol  construction  algorithm  is  proposed  first  to  derive  the  conversion  service  requirement,  and 
then  to  compose  the  final  converter  using  the  information  on  the  existing  protocol  implementation  at  a 
later  step.  The  converter  so  constructed  has  the  three  most  desirable  properties  of  a  correct  protocol 
converter;  namely,  conformity  property,  liveness  property,  and  transparency  property.  Moreover, 
the  proposed  algorithm  does  not  need  a  validation  phase  at  the  end  to  ensTire  the  correctness  of  the 
converter  as  long  as  the  protocols  being  converted  are  by  themselves  correct  £ind  the  given  conversion 
service  requirement  and  service  specifications  are  also  correct;  i.e.  fi’ee  from  deadlock  and  livelock.  In 
addition,  the  algorithm  has  the  capability  to  handle  the  conversion  between  sequences  of  transitions 
in  different  protocols.  This  capability  is  crucial  when  dealing  with  complex  protocols  in  which  the 
semantics  of  sequences  of  transitions/messages  is  different  from  that  of  a  simple  concatenation  of  the 
semantics  of  each  originail  individuad  transition/message  and  the  conversion  can  oidy  be  done  in  a 
unit  of  sequence  of  transitions /messages. 

Another  major  contribution  of  this  pairt  of  the  research  is  that  a  more  efficient  conversion  model, 
called  compensation  model,  is  proposed  to  replace  the  traditionad  intermediate  converter  model  for 
performing  protocol  conversion  on  multimedia  networks  [10].  Under  this  protocol  compensation 
model,  the  Synchronizing  Transition  Set  algorithm,  is  extended  amd  modified  to  accoimnodate  the 
high  speed  and  high  coimectivity  of  the  multimedia  networks.  The  modified  adgorithm  still  retained 
all  the  desirable  strengths  of  the  originad  adgorithm. 


2.2.2  Conformance  Testing 

For  test  airchitecture,  a  computer-aided  protocol  design  methodology  based  on  a  single  representation 
mechanism,  the  OPS5  production  system  [35],  is  proposed  to  formadly  model  the  specification,  vadi- 
dation,  implementation  auid  test  phases  [14].  To  provide  for  direct  control  and  observation  during  the 
test  phase,  the  proposed  architecture  has  (1)  a  single  high  level  representation  mechanism  to  be  used 
in  both  design  phase  and  test  phase;  (2)  a  Test  sequence  Generator  and  state  Monitor  (TGM)  that  is 
added  to  the  locad  environment.  By  using  a  single  representation  mechanism  approach,  protocol  test 
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sequence  generation  is  formally  represented  in  production  rules  by  combining  those  related  elements 
in  the  formal  protocol  specification  with  additional  elements  used  for  controllability  and  observability 
in  the  test  process.  With  the  improved  observability,  the  state  of  the  implementation  can  be  directly 
verified  by  checking  the  implementation  state  recorded  after  the  application  of  a  transition;  with  the 
improved  controllability,  the  status  of  the  implementation  can  be  set  to  the  head  state’s  status  of 
the  transition  to  be  tested. 


For  test  sequence  generation,  our  contribution  can  be  sunamarized  into  two  major  areas.  The  first 
area  is  on  the  test  procedures  for  protocol  specified  in  Finite  State  Machine  (FSM).  The  second  area 
is  on  the  Extended  Finite  State  Machine  (EFSM)  which  is  more  effective  than  the  FSM  in  describing 
complex  protocols.  Our  results  in  EFSM  is  important  since  there  is  little  research  done  in  this  area. 

For  protocols  specified  in  FSM,  our  major  contribution  is  to  improve  the  test  coverage  and 
the  length  of  test  sequences  based  on  the  umque  input /output  (UIO)  method  [36].  UIO  is  the  most 
popular  test  sequence  generation  method  for  FSM.  It  has  been  improved  to  have  better  fault  coverage 
by  the  revised  UIO  method,  called  UIOv  method  [37].  However,  the  UIOv  method  always  needs  a 
complete  verification  part.  We  propose  a  method  that  needs  only  a  minimal  verification  part.  Our 
method  [13]  has  the  same  applicability  as  the  UIOv  method.  In  addition,  our  method  uses  a  simple 
test  on  a  given  specification  to  decide  whether  a  verification  part  is  needed  for  detecting  transfer 
faults  in  the  protocol  implementation.  Furthermore,  if  a  verification  part  cannot  be  completely 
omitted  for  detecting  transfer  faults,  our  method  can  generate  a  minimal  niimber  of  input/output 
sequences  for  a  verification  part.  In  addition,  two  new  approaches  [17]  are  proposed  to  generate 
Tninimal  length  test  sequences  by  using  multiple  UIOs  and  segment  overlap.  The  first  approach 
does  not  verify  the  uniqueness  of  UIO  sequences  of  states,  but  the  second  approach  does.  Among 
test  sequence  minimization  methods,  the  two  approaches  have  the  best  applicability,  and  our  second 
method  has  the  best  fault  coverage. 

In  addition,  a  new  approach,  called  Transition  State  Pair  (TSP),  is  also  developed  for  testing 
protocols  specified  in  FSM  [21].  The  TSP  method  has  three  advantages  over  the  W  method  [38]  and 
the  Wp  method  [39].  First,  the  TSP  method  can  derive  a  test  sequence  not  only  for  any  minimal 
and  fully  specified  protocols  but  also  for  minimal  and  parti£il  specified  protocols.  Second,  the  TSP 
method  uses  less  time  to  derive  test  sequences.  Third,  it  derives  shorter  test  sequences. 

For  EFSM,  our  main  restdts  are  to  propose  an  axiomatic  approach  for  generating  test  sequences. 
To  construct  test  sequences  for  EFSM,  one  must  have  a  way  to  trace  the  chemges  and  dependencies 
of  the  data  items.  A  technique  used  in  program  proving,  called  axiomatic  semantics  [40],  is  found 
to  be  useful  tool  for  serving  such  a  purpose.  Axiomatic  semantics  provides  a  set  of  axioms  that 
describes  the  general  rules  of  how  the  status  of  a  program,  called  assertions,  is  changed  before  and 
after  a  statement.  Depending  on  how  the  axioms  are  written,  one  can  monitor  different  properties 
of  a  program  and  use  the  properties  for  different  purposes.  It  is  found  that  one  can  design  the  axiom 
in  such  a  way  that  after  a  program  is  evaluated,  the  resulting  assertion  contains  a  test  sequence. 
Based  on  this  idea,  a  test  procedure  is  proposed  [15].  An  improved  version  that  simplifies  the  axioms, 
assertions,  and  the  algorithms  is  also  proposed  [5]  so  that  the  axiomatic  approach  can  be  easily  applied 
to  any  statement  set.  To  extend  the  power  of  the  approach,  a  method  that  takes  in  a  requirement 
as  a  guide  to  generate  test  sequences  for  checking  requirement  conformity  is  proposed  [23].  Most  of 
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the  test  sequence  generation  methods  check  transfer  errors  which  are  syntactic  in  nature.  By  using 
the  requirements,  semantic  can  be  introduced  into  conformity  testing.  This  enables  test  sequences 
to  be  generated  with  meaningful  test  purposes. 

In  addition,  since  methods  of  generating  test  sequences  for  testing  EFSM  focus  mainly  on  the  data 
flow  aspect  of  a  specification,  the  control  aspect  of  the  specification  is  ignored.  In  order  to  enhance 
the  power  of  test  sequences  for  EFSM,  a  method,  called  effective  domain  for  testing,  is  proposed 

[27]  to  introduce  UIO  check  sequences  into  the  testing  of  the  data  flow  of  a  protocol  specification 
modeled  by  EFSM.  By  using  the  concept  of  effective  domain,  one  can  reduce  the  overall  length  of 
test  sequences  needed  for  checking  both  control  flow  and  data  flow. 

Furthermore,  a  more  flexible  method  is  also  proposed  [18]  for  generating  test  sequences  for  a 
given  fault  model.  Currently,  most  of  the  test  generation  procedures  appearing  in  the  literatme 
generate  test  sequences  to  detect  a  specific  type  of  errors,  called  a  fault  model.  Since  a  test  method 
is  designed  for  a  fixed  fault  model,  the  ability  of  detecting  errors  in  the  implementation  is  limited. 
To  detect  other  types  of  faults,  a  procedure  that  can  generate  test  sequences  based  on  a  given  fault 
model  is  proposed.  This  method  has  also  been  extended  [20]  to  generating  test  sequences  for  protocol 
specification  written  in  the  Estelle  [41]  which  is  an  ISO  standard  specification  language. 

To  take  advantage  of  the  availability  of  the  existing  validation  software,  a  method  is  also  proposed 

[28]  to  transform  the  problem  of  test  sequences  generation  based  on  a  fault  model  to  a  protocol 
validation  problem.  Protocol  validation  is  used  to  determine  whether  a  protocol  specification  is 
correct.  This  area  has  been  studied  for  years,  and  many  vailidation  tools  can  be  used  to  generate 
test  sequences.  By  doing  so,  we  can  use  these  validation  tools  for  the  purpose  of  test  sequences 
generation. 


2.2.3  Multimedia  Protocols 


Our  contributions  include  two  parts.  First  two  priority  schemes  are  introduced  into  local  area 
networks  [25].  They  are  bus-time  multiplexing  priority  scheme  and  station  multiplexing  scheme. 
Second,  a  multimedia  synchronization  protocol  is  proposed  [24]  to  cope  with  different  delay  jitter 
and  loss  rate  in  several  media  streams.  It  is  in  charge  of  ensuring  that  the  data  sent  in  different 
media  streams  at  the  same  time  will  also  arrive  at  the  destinations  at  about  the  same  time  within 
an  acceptable  tolerance. 

To  provide  timely  delivery  of  multimedia  data  in  traditional  local  zirea  networks,  two  level  of 
priorities,  high  priority  (for  multimedia  or  real-time  traffic)  and  low  priority  (for  regular  data),  are 
introduced  for  data  transmission  [25].  Since  traditional  local  area  networks  do  not  support  any 
priority  scheme,  we  propose  two  priority  schemes  for  implementation  in  them.  The  basic  idea  behind 
these  schemes  is  to  let  the  stations  wishing  to  transmit  multimedia  data  inform  other  stations  to 
withhold  from  transmitting  etny  regular  data.  Simulation  results  show  that  by  incorporating  these 
priority  schemes  into  local  cirea  networks,  response  time  for  multimedia  traflic  is  improved  cind  packets 
discarding  possibilities  for  multimedia  data  packets  are  reduced. 
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The  multimedia  synchronization  protocol  we  proposed  [24]  serves  as  an  interface  between  the 
underlying  ATM  network  and  the  multimedia  appUcations.  It  consist  of  two  entities,  the  marker, 
which  insert  some  control  cells,  called  sync  cells,  into  the  media  streams  to  mark  the  places  where 
data  should  be  synchronized,  and  the  synchronizer,  which  recognizes  the  control  ceUs  and  ^gn  the 
data  deUvery  in  different  media  streams.  To  cope  with  the  loss  of  sync  ceU,  three  pohcies,  drop-old, 
transmit-old  and  delayed-transmit,  are  considered  for  implementation  within  the  syncl^omzation 
protocol  For  these  three  poUcies,  the  translation  from  the  quality  of  service  (QOS)  specified  by  the 
multimedia  applications  into  the  QOS  for  the  ATM  network  has  been  analyzed.  According  to  these 
analysis  it  can  be  deduced  that  the  drop-old  policy  is  more  demanding  on  network  ceU  loss  rate. 
Howeve^  the  drop-old  policy  is  less  restrictive  on  network  delay  requirement.  The  delayed-transmit 
policy  imposes  stronger  demand  on  network  delay,  but  it  allows  a  smaUer  portion  of  ceUs  to  be 
received  correctly  in  that  delay  period.  In  addition,  it  requires  a  smaller  buffer  size. 


2.2.4  High-Speed  Packet  Switches 


Our  main  contributions  include  two  parts.  First,  a  new  indirect  star-type  network,  caUed  the 
star  network  [6],  is  proposed.  The  /r-star  network  is  an  indirect  star  network.  It  is  obtained  by 
an  unfolding  scheme  appUed  to  the  star  graph  based  on  its  recursive  property.  Being  a  star-type 
network,  the  proposed  /i-star  network  inherits  all  the  good  properties  from  the  star  graph.  The  star 
graph  has  a  smaUer  degree  and  diameter  than  the  weU-known  n-cube,  and  can  be  an  alternative  to 
the  n-cube  for  systems  with  a  large  number  of  nodes.  It  also  is  symmetric,  highly  modular,  strongly 
hierarchical,  and  maximally  fault-tolerant  [42,  43,  44,  45],  like  n-cube  type  network.  Because  of  its 
symmetry,  the  star  graph  is  easily  extensible  and  can  be  decomposed  in  many  different  ways.  Its 
routing  algorithm  is  also  very  simple.  The  star  graph  is  Hamiltonian.  Efficient  sorting  algorithms,  a 
collection  of  application  algorithms  and  a  parallel  algorithm  for  computing  fast  Fourier  transforms 
on  the  star  graph  are  available  [46,  47,  48,  49]. 

The  ^-star  network  is  modular.  Therefore,  a  large  /i-star  network  can  be  bmlt  from  smaller 
ones.  The  performance  of  the  /i-star  network  has  been  analyzed  under  the  umform  traffic  model  and 
shown  to  be  almost  identical  to  that  of  the  indirect  cube-type  network  based  on  (2  X  2)  switches. 
Its  performance  also  shows  that  it  is  an  improvement  over  previously  proposed  indirect  star- type 
networks  [50].  The  routing  of  the  /i-star  network  is  simple  and  the  routing  decision  can  be  made 
locally  within  each  of  the  switches  in  the  network.  The  /i-star  network  can  be  an  alternative  to  the 
indirect  cube-type  network  when  the  network  size  is  close  to  a  factorial  rather  than  a  power  of  a 

integer. 

Our  second  contribution  is  to  present  a  new,  and  more  general  analytic  model  [8]  for  the  Knockout 
Switch.  The  Knockout  Switch  is  a  nonblocking,  high  performance  switch  suitable  for  broadband 
packet  switching.  It  allows  packet  losses,  but  the  probability  of  a  packet  loss  can  be  kept  extremely 
small  in  a  cost-effective  way.  The  performance  of  the  Knockout  Switch  was  analyzed  under  uniform 
traffic  [51],  and  it  shows  that  the  Knockout  Switch  does  have  extremely  low  packet  loss  probabilities 
under  uniform  traffic.  In  this  part  of  research,  we  propiosed  a  more  general  analytical  model  to 
analyze  the  lost  packet  probabilities  and  the  effectiveness  of  the  Knockout  Switch  under  various 
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nonuniform  traffic  patterns.  This  analytic  model  is  an  approximate  Markov  chain.  It  integrates  the 
effects  of  the  concentrator  and  the  shared  buffer  on  the  lost  packet  probability,  and  allows  any  traffic 
patterns. 

The  accuracy  of  the  new  analytic  model  is  verified  by  comparing  the  numeric  results  obtained 
from  the  new  model  to  the  known  results  for  uniform  traffic  in  [51].  This  research  shows  that  the 
(1024  X  1024)  Knockout  Switch  is  stable  imder  hot-spot  traffic  with  the  buffer  size  of  40  and  the 
threshold  of  8,  if  the  hot-spot  load  is  limited  to  keep  the  lost  packet  probability  <  10~®.  Once  the 
hot-spot  load  becomes  higher  than  these  cut-off  points,  the  lost  packet  probability  becomes  higher 
than  10“®.  At  this  point,  increased  buffering  and  threshold  do  not  help.  We  observed  the  same 
phenomenon  for  smaller  network  sizes,  too.  This  suggests  the  importance  of  regulating  the  hot-spot 
load  within  the  range  not  to  overload  the  hot-spot  to  keep  the  Knockout  Switch  stable.  Under 
the  mixed  point-to-point/uniform  traffic  that  has  particular  significance  of  mixed  voice,  data,  and 
video  applications,  the  analytical  result  shows  that  the  Knockout  Switch  is  stable  given  sufficient 
buffers.  The  research  result  also  shows  that  Knockout  Switch  performs  stably  under  two  other 
nonuniform  traffic  patterns,  pattern  I  and  pattern  II.  On  the  contrary,  it  has  been  shown  in  [52]  that 
the  multistage  packet  switches,  such  as  Banyan  networks,  sigmficantly  degrades  their  performance 
under  these  traffic  models.  In  addition,  the  research  result  shows  that  the  buffer  size  needs  to  be 
increased  from  40  to  80  to  keep  the  lost  packet  probabilities  under  10“®  under  the  point-to-point 
traffic  and  traffic  pattern  I. 


2.2.5  Distributed  Control 


In  the  area  of  distributed  databases,  our  major  contribution  is  that  an  integrated  approach,  including 
a  rule  decomposition  scheme,  a  distributed  algorithm  and  a  distributed  evaluation  algorithm,  is  used 
for  processing  complicated  rules  in  distributed  active  databases  [12,  7,  22].  The  decomposition 
scheme  uses  a  new  relational  operator,  AND,  to  identify  independent  parts  of  a  rule  query  and  to 
facilitate  the  distribution  of  subrules.  The  distribution  of  the  subrules  wiU  adapt  to  the  relation 
distribution,  which  has  not  been  investigated  before.  The  distributed  evaluation  algorithm  makes 
use  of  the  different  types  of  nodes  derived  from  the  AND  operator  to  collect  and  combine  local 
results  to  derive  a  consistent  global  rule  evaluation  result.  A  consistent  global  evaluation  result 
is  difficult  to  achieve  due  to  the  distributed  environment  and  has  not  been  addressed  previously 
in  distributed  rule  processing.  The  concept  of  simultaneous  regions  is  applied  to  distributed  rule 
evaluation  to  achieve  consistency  and  correctness.  The  performance  analysis  of  the  distributed 
evaluation  algorithm  suggests  that  fatter  trees  are  preferable  to  taller  trees  in  terms  of  the  response 
time  eind  the  message  count. 

In  the  area  of  distributed  operating  systems,  we  proposed  an  intelligent  job  selection  policy 
that  learns  the  behavior  of  the  wide  veiriety  of  job  types  that  make  up  the  workload  of  a  typical 
distributed  system  [19].  A  learning  mechanism,  called  weight  climbing,  is  used  to  gather  knowledge 
of  how  each  type  of  job  behaves.  Based  on  this  knowledge,  our  selection  policy  decides  which 
jobs  can  be  advantageously  transferred  imder  the  current  conditions.  Such  a  job  scheduler  has  the 
following  advantages:  first,  the  job  transfer  decision  is  made  based  not  only  on  current  conditions. 


11 


but  on  detailed  characteristics  of  the  specific  job  being  considered.  Second,  knowledge  of  these 
characteristics  is  accurate,  because  it  is  acqtdred  through  continmng  observation  on  the  particular 
system  in  which  transfer  is  being  considered.  Third,  whenever  the  system  configuration  or  workload 
changes,  the  scheduler  can  relearn  the  situation  and  adapt  itself  automatically.  Our  experimental 
results  show  that  our  intelligent  selection  policy  is  able  to  learn  job  behavior  quickly  and  to  m^e 
decisions  accordingly.  The  performance  of  our  policy  is  compared  with  that  of  the  Threshold  policy 
[53].  The  results  show  that,  as  our  policy  learns  job  behaviors,  it  is  able  to  sigiuficantly  improve 
performance  relative  to  the  Threshold  policy.  The  results  also  show  that  our  policy  automatically 
adapts  to  system  configuration  or  program  behavior  changes.  The  job  selection  policy  we  proposed 
not  only  takes  both  the  characteristics  of  the  jobs  and  the  current  system  environment  into  account, 
but  also  adapts  to  rbanging  job  characteristics  and  environments.  These  features  are  provided  with 
negligible  time  and  space  overhead. 
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Abstract 

With  the  proliferation  of  different  network  architec- 
tures,  it  has  been  recognized  that  protocol  conversion 
is  needed  for  achieving  the  interoperability  between 
computer  networks  that  implement  different  proto¬ 
cols  [1,  2,  3].  Since  1986,  many  protocol  converter 
construction  algorithms  based  on  formal  models  have 
been  proposed.  In  the  meantime,  it  has  been  observed 
by  many  researchers  that  algorithms  based  on  service 
specification  have  in  general  less  complexity  at  the  de¬ 
sign  stage.  In  this  paper,  a  five-step  algorithm  is  pro¬ 
posed  to  formally  derive  a  protocol  converter  from  the 
service  specification:  (1)  Generate  the  Service  System 
Graph  from  the  given  service  specifications;  (2)  Derive 
the  Conversion  Service  Specification  from  the  service 
system  graph;  (3)  Generate  the  Synchronizing  Transi¬ 
tion  Sets  from  the  conversion  service  specification;  (4) 
Compose  the  converter  using  the  synchronizing  transi¬ 
tion  sets;  and  (5)  Remove  the  remaining  service  transi¬ 
tions  to  obtain  the  final  Protocol  Converter  Specifica¬ 
tion.  The  converter  so  constructed  has  the  three  most 
desirable  properties  of  a  correct  protocol  converter; 
namely,  conformity  property  (also  known  as  maximum 
safety  property),  liveness  property,  and  transparency 
property.  Moreover,  unlike  many  other  protocol  con¬ 
version  algorithms,  the  proposed  algorithm  does  not 

^Research  reported  herein  was  supported  by  U.S.  Army  Re¬ 
search  Office,  under  contract  Nos.  DAAL03-91-G-0093  and 
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tained  in  this  paper  are  those  of  the  authors  and  should  not 
be  construed  as  an  official  Department  of  the  Army  position, 
policy  or  decision. 


need  a  validation  phase  at  the  end  to  ensure  the  cor¬ 
rectness  of  the  converter  as  long  as  the  protocols  being 
converted  are  by  themselves  correct  and  the  given  con¬ 
version  service  requirement  and  service  specifications 
are  also  correct;  i.e.  free  from  deadlock  and  livelock. 
The  reason  is  that  the  proposed  algorithm  preserves 
all  the  properties  and  functionalities  of  the  original 
protocols  during  the  derivation  of  the  converter.  In 
addition,  it  has  the  capability  to  handle  the  conversion 
between  sequences  of  transitions  in  different  protocols. 
This  capability  is  crucial  when  dealing  with  complex 
protocols  in  which  the  semantics  of  sequences  of  tran¬ 
sitions/messages  is  different  from  that  of  a  simple  con¬ 
catenation  of  the  semantics  of  each  original  individ¬ 
ual  transition/message  and  the  conversion  can  only 
be  done  in  a  unit  of  sequence  of  transitions /messages. 
For  ease  in  specification  and  discussion,  the  formal 
CFSM  (Communication  Finite  State  Machine)  model 
is  adopted  in  this  paper.  Nevertheless,  the  same  al¬ 
gorithm  can  be  ecisily  extended  to  work  effectively  in 
the  Extended  Finite  State  Machine  (EFSM)  model  as 
well  [4]. 

Keywords:  synchronizing  transition  set,  protocol  con¬ 
version,  protocol  converter,  protocol  specification,  ser¬ 
vice  specification 

1  Introduction 

With  the  development  of  a  variety  of  networks  in  re¬ 
cent  years,  internetworking  between  different  networks 
has  become  an  important  issue  since  users  on  differ- 
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ent  networks  need  to  communicate  with  each  other. 
Due  to  the  so  called  protocol  mismatches  [1],  proto¬ 
col  conversion  has  become  a  necessity  for  internet¬ 
work  communication  in  a  heterogeneous  network  en¬ 
vironment.  In  [1],  Green  analyzed  different  internet¬ 
work  architectures  and  situations  in  which  conver¬ 
sion  has  to  be  performed.  Even  in  an  ideal  case  in 
which  the  convergence  into  worldwide  standard  pro¬ 
tocols  may  reduce  the  need  of  conversion,  it  is  still  far 
away  from  being  practical,  simply  because  of  the  high 
cost  and  other  reasons.  In  fact,  recent  development  in 
the  worldwide  ISDN  (Integrated  Services  Digital  Net¬ 
work)  adopts  an  evolutionary  instead  of  a  revolution¬ 
ary  approach;  this  trend  further  indicates  the  necessity 
of  protocol  conversion.  Consequently,  the  conversion 
problem,  arising  from  the  need  for  constructing  a  con¬ 
verter  that  provides  interoperability  between  different 
network  protocols,  has  become  an  important  design 
issue  in  computer  communication. 

During  the  past  decade,  a  number  of  conversion  al¬ 
gorithms  have  been  proposed.  Many  of  them  construct 
converters  in  an  ad  hoc  manner  [5,  6,  7,  8].  On  the 
other  hand,  following  Green’s  pioneering  work  in  [1], 
many  algorithms  based  on  formal  models  have  also 
been  proposed.  It  is  believed  that  to  solve  the  proto¬ 
col  conversion  problem  efficiently  and  once  for  all,  the 
formal  method  is  the  right  direction  to  follow.  In  this 
paper,  a  five-step  conversion  algorithm  based  on  the 
CFSM  (Communication  Finite  State  Machine)  model 
is  proposed  to  formally  derive  a  protocol  converter 
from  a  service  specification. 

Among  those  formal  methods  proposed  by  differ¬ 
ent  researchers,  there  are  in  general  two  different  ap¬ 
proaches:  Conversion  Specification  and  Service  Spec¬ 
ification.  To  derive  a  protocol  converter,  the  con¬ 
version  specification  approach  takes  directly  as  in¬ 
put  the  original  protocol  specifications  and  the  given 
conversion  specification,  which  is  in  a  similar  form 
as  the  protocol  specification,  as  illustrated  in  Fig.  1. 
Essentially,  the  conversion  specification  either  tells 
how  to  translate  the  messages  between  protocols  or 
specifies  the  ordering  of  the  given  protocol  transi¬ 
tions  to  synchronize  the  execution  of  the  given  pro¬ 
tocol  entities.  In  other  words,  the  conversion  speci¬ 
fication  tells  how  to  perform  the  protocol  conversion 
for  the  given  protocols.  The  algorithms  proposed  in 
[9,  10,  11,  12,  13,  14,  15,  16]  belong  to  this  category. 

One  of  the  shortcomings  of  the  conversion  specifica¬ 
tion  approach  is  that  the  implementation  details  are 
involved  at  the  early  stage  of  design,  thereby  resulting 
in  a  more  complex  algorithm.  In  addition,  there  is  no 


formal  algorithm  for  generating  the  conversion  specifi¬ 
cation,  which  is  usually  obtained  in  an  ad  hoc  manner. 
This  is  a  very  serious  drawback,  especially  for  those 
complex  protocols  whose  conversion  specifications  are 
hard  to  find  in  ad  hoc  ways. 

On  the  other  hand,  the  service  specification  ap¬ 
proach,  which  has  received  more  and  more  attention 
in  recent  years,  treats  the  implementation  details  as 
unknown  black  boxes  at  the  early  stage  of  design;  it 
only  depicts  the  final  behavior  of  the  overall  protocol 
system  as  a  to-be-found  converter  from  the  viewpoint 
of  the  protocol  service  users  at  the  SAP  (Service  Ac¬ 
cess  Point).  The  service  specification  is  specified  in 
terms  of  the  Service  Transitions  to  be  executed  at  the 
SAPs.  Fig.  2  shows  the  high  level  concept  of  the  ser¬ 
vice  specification  approach.  The  algorithms  proposed 
in  [17,  18,  19,  20,  21]  belong  to  this  category. 

Due  to  its  high  level  of  abstraction,  finding  a  correct 
service  specification  at  the  protocol  service  user  level 
is  easier  and  more  practical  than  finding  the  conver¬ 
sion  specification  in  an  ad  hoc  manner  by  examining 
the  implementation  of  the  given  protocols.  However, 
the  difficulty  of  the  service  specification  approach  is, 
in  general,  that  the  service  specification  by  itself  does 
not  tell  directly  how  to  perform  the  protocol  conver¬ 
sion.  As  a  result,  the  information  on  how  to  perform 
the  conversion  must  be  derived  from  the  given  service 
specifications  and  requirement.  Since  the  conversion 
information  derived  is  not  specific,  the  resulting  con¬ 
verter  may  not  be  correct.  Consequently,  most  of  the 
algorithms  in  this  category  require  a  validation  phase 
at  the  end  to  ensure  the  correctness  of  the  protocol 
converter  constructed.  This  not  only  complicates  the 
construction  procedure  but  also  means  that  when  the 
validation  fails,  the  procedure  has  failed  to  find  a  con¬ 
verter  for  the  given  service  specifications  and  require¬ 
ment.  Moreover,  even  when  the  validation  phase  may 
pass,  the  converter  so  constructed  often  covers  only  a 
subset  of  the  properties  and  functionalities  of  the  orig¬ 
inal  protocols  [3,  21].  This  drawback,  as  was  observed, 
is  due  to  the  fact  that  the  information  on  the  existing 
protocol  implementation  was  not  taken  into  consider¬ 
ation  during  the  converter  construction  process. 

Due  to  the  fact,  that  for  a  given  service  specification 
there  may  be  a  number  of  different  implementations  of 
a  protocol  (as  illustrated  in  the  example  in  Section  3 
of  this  paper),  and  the  goal  of  the  protocol  conversion 
algorithm  is  to  find  a  correct  converter  for  the  existing 
protocol  implementation,  the  information  on  the  the 
existing  protocol  specification  (implementation)  must 
be  taken  into  consideration  for  the  conversion  to  be 
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Figure  1:  The  Conversion  Specification  Approach 


correct.  In  other  words,  the  information  contained  in 
the  service  specifications  alone  is  not  sufficient  to  de¬ 
rive  a  correct  converter,  and  different  protocol  imple¬ 
mentations  of  the  same  service  specification  will  result 
in  different  protocol  converter  specifications. 

In  the  above,  it  was  claimed  that  the  information 
on  the  protocol  implementation  must  be  taken  into 
consideration  in  the  protocol  derivation  procedure.  It 
was  also  mentioned  that  to  take  advantage  of  the 
low-complexity  in  the  service  specification  approach, 
the  implementation  details  should  not  be  involved  too 
early  in  the  derivation  procedure.  In  this  paper,  a  5- 
step  protocol  converter  construction  algorithm  is  pro¬ 
posed  first  to  derive  the  conversion  service  specifica¬ 
tion  from  the  given  conversion  service  requirement, 
and  then  to  compose  the  final  converter  using  the  in¬ 
formation  on  the  existing  protocol  implementation  at 
a  later  step  (Step  4).  The  algorithm  will  always  find 
a  maximum  converter  that  meets  the  requirement  as 
specified  in  the  conversion  service  requirement,  and 
the  resulting  converter  also  always  has  the  three  most 
desirable  properties  of  a  correct  protocol  converter: 
conformity  property  (also  known  as  maximum  safety 
property),  liveness  property,  and  transparency  prop¬ 
erty.  The  conformity  property  means  that  the  con¬ 


verter  so  constructed  supports  no  more  and  no  less 
functions  than  the  original  protocols  do.  The  liveness 
property  means  that  the  converter  is  free  from  dead¬ 
lock  and  livelock  as  long  as  the  protocols  being  con¬ 
verted  and  the  conversion  service  requirement  given 
have  the  liveness  property  by  themselves.  The  trans¬ 
parency  property  means  that  the  conversion  algorithm 
does  not  alter  the  protocol  entities  at  the  end  node  of 
the  composed  protocol  system  and  the  conversion  is 
transparent  to  the  end  users. 

Another  important  capability  of  the  proposed  algo¬ 
rithm  is  that  it  is  able  to  handle  the  conversion  be¬ 
tween  sequences  of  transitions  in  different  protocols. 
This  is  a  very  encouraging  result  because  the  seman¬ 
tics  of  a  sequence  of  transitions/messages  can  be  dif¬ 
ferent  from  that  of  a  simple  concatenation  of  the  se¬ 
mantics  of  each  original  individual  transition/message 
for  complex  protocols,  and  because  many  of  the  exist¬ 
ing  conversion  algorithms  can  only  handle  mapping 
between  single  transition/message.  In  other  words, 
when  simple  one-to-one  transition/message  mapping 
between  protocols  is  not  sufficient  to  derive  a  cor¬ 
rect  converter  and  the  conversion  can  only  be  done 
in  a  unit  of  sequence  of  transitions/messages,  the  pro¬ 
posed  algorithm  can  still  derive  a  correct  converter 
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Figure  2:  The  Service  Specification  Approach 


succeesfully.  This  capability  of  performing  the  con¬ 
version  between  sequences  of  transitions  in  different 
protocols  is  demonstrated  in  Example  2  (in  Section  4) 
of  this  paper. 

The  rest  of  the  paper  is  organized  as  follows: 
Section  2  describes  the  model  and  the  specification 
method  used;  Section  3  and  Section  4  give  examples  to 
describe  the  proposed  algorithm,  and  discuss  the  ideas 
behind  each  step  of  the  algorithm  and  the  strategies 
that  can  be  used  to  reduce  the  complexity.  Section  5 
provides  a  formal  proof  of  correctness  to  show  the  rea¬ 
sons  why  an  extra  validation  step  is  not  needed  for  the 
algorithm.  Finally,  Section  6  concludes  the  paper.  For 
easy  reference,  in  outline  of  the  algorithm  is  provided 
in  Appendix. 


2  Models 

In  this  section  the  model  and  specification  method 
adopted  are  described  and  the  protocol  conversion 
problem  is  formally  defined  in  terms  of  the  specifi¬ 
cation  method  used. 

A  class  of  state-transition  systems,  called  CFSMs 
(Communication  Finite  State  Machines),  is  adopted 
for  the  protocol  specification  and  service  specification. 
A  protocol  system  consists  of  a  set  of  CFSMs  called 
protocol  entities.  Each  protocol  entity  communicates 
with  the  others  through  message  passing.  For  sim¬ 
plicity  only  2-entity  protocols  are  considered  in  this 
paper.  The  model  is  shown  in  Fig.  3. 

The  communication  channel  between  the  entities 


4 


Figure  3:  A  Protocol  System  in  CFSM  Model 


can  be  either  reliable  or  noisy.  If  the  channel  be¬ 
tween  protocol  entities  Pa  and  Pt  is  noisy,  then  the 
given  protocol  P  must  be  able  to  handle  the  noisy 
situation.  As  far  as  the  conversion  is  concerned,  the 
proposed  algorithm  covers  both  cases  since  the  func¬ 
tionalities  of  the  original  protocol  are  to  be  preserved. 
In  the  model,  however,  a  distinction  is  made  be¬ 
tween  two  kinds  of  transitions  executed  in  the  entities, 
namely,  Peer  Transitions  that  support  the  interaction 
between  two  peer  protocol  entities  and  Service  Transi¬ 
tions  that  perform  the  interaction  between  a  protocol 
entity  and  its  environment  (e.g.  the  protocol  service 
users)  through  the  SAP  (Service  Access  Point).  The 
distinction  is  made  because  of  the  observation  that 
there  are  no  service  users  on  top  of  the  final  converter 
as  depicted  in  Fig.  2  and  all  the  service  transitions 
generated  during  the  construction  process  will  be  re¬ 
moved  from  the  final  converter.  Formally,  a  CFSM 
protocol  entity  is  defined  as  follows. 

Definition  1.  A  CFSM  Protocol  Entity  Px 
is  a  six-tuple  (^,  S,  A,  S,  i,/),  where: 

1.  q  is  the  set  of  states  in  P^. 

2.  E  is  the  finite  set  of  service  transitions 
in  Pp. 

3.  A  is  the  finite  set  of  peer  transitions  in 

P.. 

4.  6  is  the  transition  function  of  Px  which 
maps  g  X  (SUA)  into  q;  if  q{si,t)  =  so, 


where  si  G  9,S2  E  g,  and  t  G  (S  U  A), 

Si  is  called  the  starting  state  of  t  and 
$2  is  the  ending  state  of  t.  Note  that  a 
receive/read  transition  tr  is  said  to  be 
executable,  only  when  the  current  state 
of  Px  is  the  starting  state  of  tr  and  the 
message  to  be  received/read  is  already 
in  the  incoming  channel  to  P^. 

5.  i  is  the  initial  state  of  Pp. 

6.  /  is  the  set  of  the  final  states  in  P^. 

Note  that  for  a  typical  non-terminating 
protocol,  /  usually  has  only  one  ele¬ 
ment,  ?  ,  which  is  the  initial  state  of  Px 

For  ease  in  discussion  it  is  assumed  in  this  paper 
that  all  the  protocol  entities  are  deterministic  finite 
state  machines,  and  that  the  protocol  specification  con¬ 
sists  of  a  set  of  CFSM  protocol  entities  so  defined. 
The  formal  definition  of  the  Service  Specification  can 
be  defined  similarly  as  follows. 

Definition  2.  A  CFSM  Protocol  Service 
Specification  P,,  (g,  S,  A,  6,  i,/),  is  a  six¬ 
tuple,  where: 

1.  g  is  the  set  of  states  in  P^. 

2.  S  is  the  finite  set  of  service  transitions 
in  Ps ,  which  is  the  union  of  the  service 
transitions  of  all  the  protocol  entities. 
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3.  A  is  the  finite  set  of  peer  transitions  in 
Pg  and  it  is  an  empty  set. 

4.  6  is  the  transition  function  of  Pg,  which 

maps  g  X  E  into  g;  if  q{si,t)  =  S2, 
where  si  G  G  g,  and  t  €  E, 

is  called  the  starting  state  of  t  and  S2  is 
the  ending  state  of  t. 

5.  i  is  the  initial  state  of  Pg. 

6.  /  is  the  set  of  the  final  states  in  Pg. 
Again,  for  a  typical  non-stopping  pro¬ 
tocol,  /  usually  has  only  one  element,  z, 
which  is  the  initial  state  of  Pg. 

As  illustrated  in  Fig.  3,  the  service  specification  de¬ 
scribes  how  the  protocol  system  functions  from  the 
viewpoint  of  the  service  users.  It  does  not  specify  how 
the  peer  entities  interact  with  each  other.  In  terms 
of  the  service  specification,  the  Protocol  Conversion 
Problem  is  formally  defined  as  follows. 

Definition  3.  Protocol  Conversion  Prob¬ 
lem. 

Given: 

1.  The  CFSM  protocol  entities  Pa^  Pb,  Qa, 

and  the  CFSM  service  specifications 
Pg  and  Qg. 

2.  The  Conversion  Service  Requirement, 

R,  which  describes  how  the  composed 
protocol  system  should  function.  R  is 
specified  in  the  same  form  as  the  CFSM 
service  specification  and  the  transition 
set  of  R  is  the  union  of  the  service  tran¬ 
sition  sets  of  Pa  and  Qh^  i.e. 

Er  =  Ep^  U  Eq^ 

Goal: 

Obtain  a  converter,  C,  as  illustrated  in 
Fig.  2.  The  converter  is  specified  in  the  same 
form  as  a  CFSM  protocol  entity  and  its  ser¬ 
vice  transition  set  is  empty.  In  addition,  C 
must  have  the  following  properties  for  cor¬ 
rectness. 

1.  Conformity  Property:  C  should  sup¬ 
port  no  more  and  no  less  functions  than 
the  original  protocols  do,  and  the  final 
protocol  system  with  the  constructed 
converter  must  conform  to  the  conver¬ 
sion  service  requirement,  R. 


2.  Liveness  Property:  C  should  be  free 
from  deadlock  and  livelock  if  P,  Q  and 
R  are  also  free  from  deadlock  and  live- 
lock. 

3.  Transparency  Property:  Pa  and  Qt 
must  be  preserved  and  can  communi¬ 
cate  with  each  other  through  C. 

Note  that  a  more  restricted  definition  of  a  correct 
protocol  converter  is  given  with  the  requirement  that 
it  must  satisfy  all  the  conformity,  liveness  and  trans¬ 
parency  properties.  It  is  believed  that  the  converter  is 
useful  only  when  these  three  properties  are  all  met. 
The  next  two  sections  (Sections  3  and  Sections  4) 
demonstrate  how  this  goal  can  be  achieved. 

3  Converter  Construction 

In  this  section  a  simple  example  is  used  to  demon¬ 
strate  how  to  apply  the  proposed  five-step  algorithm 
to  solve  the  protocol  conversion  problem  defined  in 
Section  2.  For  ease  in  understanding,  each  step  is 
briefly  described  and  then  applied  to  the  example  to 
show  the  result.  Furthermore,  as  the  algorithm  is  per¬ 
formed  step  by  step,  the  reasons  and  ideas  behind  each 
step  are  also  discussed.  For  easy  reference,  an  outline 
of  the  algorithm  is  provided  in  Appendix. 

Before  getting  into  the  details  of  the  algorithm,  the 
given  protocols,  P  and  Q,  and  the  conversion  ser¬ 
vice  requirement,  R,  are  described  below  They  are  the 
given  conditions  of  the  protocol  conversion  problem 
defined  in  Definition  3  of  Section  2. 

The  protocol  P,  as  shown  in  Fig.  4,  is  an  ABP  (Al¬ 
ternating  Bit  Protocol),  in  which.  Pa  sends  data  DO 
and  D1  alternately  to  P^.  For  each  data  sent  by 
an  acknowledgement,  AO  for  DO  and  A1  for  D1  re¬ 
spectively,  is  sent  by  P^.  The  protocol  user  at  Pa 
executes  IN  to  request  sending  of  data  and  when  data 
arrives  at  the  other  end,  Pb  executes  OUT  to  pass  the 
data  to  the  user  at  Pb>  The  ABP  is  used  in  a  noisy 
channel;  when  data  is  garbled,  it  will  be  retransmit¬ 
ted.  Note  that  ’’-f”  denotes  the  reception  of  a  message 
or  acknowledgement  and  denotes  the  sending  of  a 
message  or  acknowledgement.  The  sets  of  service  and 
peer  transitions  in  P  are  as  follows: 

Ep.  =  {  IN  } 

Ep,  =  {  OUT  } 

Ap,  =  {  -DO,  -Dl,  +A0,  -t-Al  } 

Ap,  =  {  -l-DO,  +D1,  -AO,  -A1  } 
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Figure  4:  Example  1:  The  Given  Protocol  P 


Figure  5:  Example  1: 

On  the  other  hand,  the  protocol  Q,  as  shown  in 
Fig.  5,  is  a  non-sequence  protocol.  Note  that  this 
protocol  is  used  in  a  reliable  communication  channel, 
where  garbling  of  data  is  not  possible.  As  shown  in 
Fig.  5,  for  each  data  sent  out  by  Qat  an  acknowledge¬ 
ment,  ack,  is  sent  by  Qb-  The  user  at  Qa  initiates 
the  service  transition  REG  to  hand  the  data  over  to 
Qa^  and  when  the  data  arrives  at  Qt,  it  delivers  the 
data  to  the  user  at  Qb  by  executing  DEL.  The  sets  of 
service  and  peer  transitions  in  Q  are  as  follows: 

Eg.  =  {  REG  } 

Eq,  =  {  del  } 

Xq^  =  {  -data,  +ack  } 

Xq^  =  {  -f  data,  -ack  } 

The  service  specifications,  Ps  and  Qs,  and  the  con¬ 
version  service  requirement  R  are  as  shown  in  Fig.  6. 
The  goal  in  this  example  is  to  derive  a  converter  which 


delivers  messages  from  Pa  to  For  ease  in  discus¬ 
sion,  only  one  way  of  the  traffic  (from  Pa  to  Qb)  is 
considered  in  this  paper;  the  traffic  in  the  other  direc¬ 
tion  (from  Qa  to  Pb)  can  be  carried  out  in  the  same 
way. 

Note  that  in  this  example  P  is  used  in  a  noisy  chan¬ 
nel  and  Q  in  a  reliable  channel,  and  the  informaiion 
on  the  channel  characteristic  is  not  contained  in  the 
service  specifications  P,  and  Q,.  As  a  result,  as  men¬ 
tioned  in  Section  1  of  this  paper,  P  and  Q  have  the 
same  service  specification  but  different  implementa¬ 
tions.  Since  the  goal  of  protocol  conversion  is  to  de¬ 
rive  a  converter  for  the  existing  implementations  of  P, 
(ABP)  and  Q,  (non-sequence  protocol),  one  will  not 
be  able  to  construct  a  correct  converter  for  P  and  Q 
if  no  consideration  is  made  on  how  P,  and  Q,  are  im¬ 
plemented.  This  is  why  it  was  claimed  earlier  that  the 
implementation  information  must  be  included  in  the 
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Figure  6:  Example  1:  The  Conversion  Service  Requirement  and  Service  Specifications 


derivation  of  the  protocol  converter.  (Note  that  the 
implementation  information  is  needed  at  a  later  stage 
of  the  construction  process,  but  not  at  the  first  stage 
of  the  service  specification  approach) 

3,1  Step  1:  Generate  the  Service  Sys¬ 
tem  Graph  G 

In  this  step  the  service  system  graph,  G,  is  generated 
from  the  given  ,  R  and  Q,  by  a  modified  composite 
operation,  0. 

G -<  Ps.R.Qs  >=  Ps  ^R0Qs 

The  operation  O  is  formally  defined  as  follows.. 

Definition  4.  Modified  composition  opera¬ 
tion,  (g),  on  three  CFSM  entities. 

G  =<  Ps,  R,  Qs  >=  Ps<S}R^Qs  is  a  six-tuple 
(g,  E,  A,  6,  i,/),  where 

1.  g  is  the  set  of  states  in  G  and 

q  =  {[u,  v,  w]|  u,  v,  w  are  states  of  F,, 

R  and  Qs  respectively  } 

2.  E  is  the  finite  set  of  service  transitions 
in  G  and 

E  =  Ep.  U  Eq. 

3.  A  is  the  finite  set  of  peer  transitions  in 
GandA  =  <l>(Ais  em-  ty) 

4.  6  is  the  transition  fiuiction  of  G  and 
6([u,  V,  w],  t)  = 


(a)  [u’,  V,  w]  if  t  E  Ep,  &  t  ^  Ep  ic 
6p,(u,  t)  =  u’ 

(b)  [u,  V,  w’]  if  t  €  Eg,  &  t  ^  Ep  & 
6g,(w,  t)  =  w’ 

(c)  [u’,  v’,  w]  if  t  E  Ep,  (k  t  E  Ep  Sz 
6p,(u,  i)  =  u'  k  6p(v,  t)  =  v’ 

(d)  [u,  v’,  w’]  if  t  E  Eg,  &  t  E  Ep  k 

t)  =  k  <5g.(w,  t)  =  w’ 

(e)  t  is  not  executable  at  state  [u,  v, 
w]  in  G  if  none  of  the  above  four 
conditions  is  true, 

5.  i  is  the  initial  state  of  G  and  i  = 

where  ip, ,  fp  and  ig,  are 
the  initial  states  of  F,,  R  and  re¬ 
spectively. 

6,  /  is  the  set  of  the  final  states  in  G  and 

/  =  /q.]}  (= 

The  service  system  graph  G,  constructed  by  the 
modified  composition  operation,  0,  describes  how  the 
protocols  P  and  Q  work  together  as  a  composed  proto¬ 
col  system  to  perform  the  functions  requested  by  the 
conversion  service  requirement  R.  Note  that  G  does 
not  contain  any  peer  transition  and  it  describes  the 
behavior  of  the  composed  protocol  system  at  the  ser¬ 
vice  transition  level  (i.e.,  at  SAP).  The  result  of  ap¬ 
plying  the  modified  composition  operation  0  to  Fj,  R 
and  Qs  in  this  example  to  obtain  the  service  system 
graph  G  is  shown  in  Fig.  7. 

The  difference  between  the  modified  composition 
operation  0  and  the  usual  composition  operation  de- 
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Figure  7:  The  Service  System  Graph  G  of  Example  1 


fined  in  [3]  is  as  follows:  in  the  modified  composition 
operation  0,  a  transition  t  belonging  to  both  P,  and 
R  is  executable  in  G  only  when  both  Pg  and  R  are 
ready  to  execute  it;  i.e.  both  P,  and  R  have  to  reach 
the  starting  state  of  t  for  t  to  be  executable  in  G.  The 
same  is  true  for  those  transitions  belonging  to  both  R 
and  Qs.  Note  that  this  difference  is  enforced  by  items 
4,c  and  4.d  of  Definition  4. 

As  shown  in  Fig.  7,  at  state  [1,  2,  1],  transition  IN 
to  state  [2,  2,  1]  is  not  executable  in  G  when  using  the 
modified  composition  operation  0,  since  IN  E  Sp,  & 
IN  €  S/i  and  IN  is  not  executable  at  state  2  of  R, 
even  though  IN  is  executable  at  state  1  of  P,.  On 
the  other  hand,  in  the  usual  composition  operation 
defined  in  [3],  the  transition  IN  from  state  [1,  2,  1]  to 
state  [2,2,  1]  would  have  been  allowed.  The  transition 
sequence 

Pr  =  IN.OUT.IN.OUT.REC.DEL 

would  become  a  legal  path  in  G,  if  the  transition  IN 
from  state  [1,  2,  1]  to  state  [2,  2,  1]  were  allowed  in  G. 
It  is  easy  to  verify  that  the  transition  sequence  px  does 
not  obey  the  rule  specified  in  the  conversion  service 
requirement,  R,  which  essentially  says  that  each  IN 


must  be  followed  by  one  DEL  in  a  legal  path.  To  be 
more  specific,  the  projection  of  onto  Px  Ie/?  (= 
IN.IN.DEL),  which  has  two  INs  and  only  one  DEL, 
is  not  accepted  by  R,  and  as  a  result  px  should  not 
be  a  legal  path  of  G.  Therefore,  items  4.c  and  4.d  of 
Definition  4  are  used  to  exclude  from  G  the  transition 
IN  from  state  [1,  2,  1]  to  state  [2,  2,  1],  thereby  making 
the  transition  sequence  px  (which  does  not  meet  the 
requirement  R)  an  illegal  path  in  G.  Note  that  a  legal 
path  of  a  CFSM  in  this  paper  is  defined  as  a  sequence 
of  transitions  which  starts  and  ends  at  the  initial  state. 

One  may  argue  that  G  could  lose  some  functional¬ 
ities  from  the  original  protocols  if  the  transition  IN 
from  state  [1,  2,  1]  to  state  [2,  2,  1]  were  not  included. 
The  answer  to  this  argument  is  that  the  capability 
of  executing  the  transition  IN  is  not  taken  out  from 
G  (hence  no  loss  of  functionality)  after  applying  the 
modified  composition  operation  0  to  P^,  R  and  Q,. 
The  transition  IN  is  indeed  included  at  some  other 
starting  states  (state  [1,  1,  1]  and  state  [1,  1,  2]  but 
not  state  [1,  2,  1])  to  make  the  final  service  system 
graph  G  obey  all  the  rules  specified  by  P,,  R  and  Q,. 
By  going  through  G,  it  is  clear  that  the  legal  paths 
accepted  by  G  are  a  mixture  of  the  transitions  in  P, 


and  Qs  in  an  order  that  follows  the  sequencing  pre¬ 
scribed  by  the  conversion  service  requirement  R  and 
the  given  service  specifications  P,  and  Qg.  In  short,  G 
describes  how  the  protocols  work  together  to  provide 
the  service  required,  under  the  constraints  of  the  given 
conversion  service  requirement  R. 

3.2  Step  2:  Derive  the  Conversion  Ser¬ 
vice  Specification  M 

As  mentioned  earlier,  the  conversion  service  require¬ 
ment  R  (hence  also  the  derived  service  system  graph 
G)  only  describes  how  the  final  protocol  system  should 
function  and  neither  R  nor  G  tells  specifically  how  the 
conversion  should  be  performed.  The  information  on 
how  to  perform  the  conversion  is,  however,  implied  in 
G,  and  the  goal  of  this  step  is  to  derive  this  infor¬ 
mation  from  G.  Note  that  the  conversion  can  happen 
only  between  Ph  and  Qa.  To  know  how  the  conversion 
can  be  done,  the  relationship  between  the  transitions 
in  Ph  and  Qa  must  be  derived  first.  By  projecting  G 
onto  Epj,  U  one  can  derive  a  conversion  service 
specification  M,  which  has  only  transitions  of  Ph  and 
Qa  and  describes  the  necessary  sequencing  of  the  tran¬ 
sitions  in  Ph  and  Qa  to  provide  the  service  required  in 
R;  i.e.  M  (=  G  Isp^uSg^)  describes  how  the  service 
transitions  of  Ph  and  Qa  interact  to  perform  the  ser¬ 
vice  requested  in  R.  The  projection  operation,  |,  which 
is  the  same  as  that  defined  in  [3],  is  formally  defined 
as  follows. 

Definition  5.  Project  Operation,  |. 

M  —  G  is  a  CFSM  derived  from  G 

by  the  following  steps: 

1.  Change  the  transitions  of  G  not  belong¬ 
ing  to  Ep^  U  Eq^  into  null  transitions. 

2.  Removing  all  null  transitions  using  the 
algorithm  described  in  [22]. 

As  a  matter  of  fact,  in  this  step  the  adaptor  conver¬ 
sion  model  is  being  adopted.  The  adaptor  conversion 
model  is  shown  in  Fig.  8,  where  the  adaptor  performs 
the  conversion  by  synchronizing  the  execution  of  the 
service  transitions  of  Ph  and  Qa\  i  e.  the  conversion 
service  specification  M  specifies  the  proper  (service) 
transition  sequence  of  the  adaptor  for  the  protocol  sys¬ 
tem  to  perform  the  functions  requested  by  the  require¬ 
ment  R.  Note  that  M  (hence  also  the  adaptor)  contains 
only  service  transitions  and  all  service  transitions  are 
later  to  be  removed  from  the  final  converter.  In  Step  5 
of  the  algorithm  when  all  the  service  transitions  are 


removed  from  the  converter,  Fig.  8  is  eventually  trans¬ 
formed  into  the  converter  conversion  model  depicted 
in  Fig.  9. 

The  result  of  applying  the  projection  operation  to 
the  service  system  graph  G  obtained  in  Step  1  to  de¬ 
rive  the  conversion  service  specification  M  is  shown  in 
Fig.  10  and  Fig.  11.  Part  A  of  Fig.  10  shows  the  initial 
projection  of  G  onto  Ep^,  U  Eq^  .  The  removal  of  states 
involving  null  transitions  is  shown  in  parts  B,  C  and  D 
of  Fig.  10  and  Fig.  11.  The  resulting  Fig.  11  shows 
the  Conversion  Service  Specification,  M,  obtained  af¬ 
ter  the  completion  of  the  project  operation. 

Note  that  a  state  with  only  one  null  outgoing  tran¬ 
sition  can  be  removed  simply  by  changing  the  ending 
states  of  all  the  incoming  transitions  into  the  ending 
state  of  the  null  outgoing  transition  as  shown  in  part 
A  to  part  B  of  Fig.  10,  where  state  4  is  removed.  Sim¬ 
ilarly,  a  state  with  only  one  null  incoming  transition 
can  be  removed  simply  by  changing  the  starting  states 
of  all  the  outgoing  transitions  into  the  starting  state 
of  the  null  incoming  transition  as  shown  in  part  B  to 
part  C  and  part  C  to  part  D  of  Fig.  10,  where  state 
7  is  removed  in  part  C  and  state  2  is  removed  in  part 
D.  Examining  Fig.  11,  it  is  obvious  that  the  transition 
sequence  REC.OUT  accepted  by  M  is  semantically  in¬ 
correct,  since  it  means  that  Qa  can  send  out  the  data 
to  Qh  before  Ph  hands  over  the  data  received  from 
Pa  to  Qa,  However,  by  examining  the  given  service 
specifications  P,  and  Q^  and  the  conversion  service 
requirement  R,  what  they  have  specified  are  as  fol¬ 
lows: 

Ps’.  an  IN  must  be  followed  by  an  OUT  (IN 
-  OUT). 

R:  an  IN  must  be  followed  by  a  DEL  (IN  — ► 
DEL). 

Qs'.  a  REC  must  be  followed  by  a  DEL  (REC 
^  DEL). 

Note  that  M  is  a  projection  of  G  and  REC.OUT  is  just 
a  sub-sequence  of  transitions  of  some  legal  paths  of  G. 
The  transition  sequence  REC.OUT  does  not  violate 
the  rules  as  long  as  an  IN  was  executed  earlier  and 
a  DEL  is  executed  later  in  the  original  legal  paths  of 
G  (e.g.  IN. REC. OUT. DEL).  The  given  specifications 
do  not  specify  specifically  what  the  correct  ordering  of 
OUT  and  REC  should  be,  and  the  ordering  of  OUT 
and  REC  is  left  to  be  determined  by  the  implemen¬ 
tation  of  the  converter  from  the  service  users’  view¬ 
point.  Therefore,  this  further  shows  the  validity  of 
the  claim  made  earlier  that  the  information  from  ser¬ 
vice  specification  alone  is  not  sufficient  to  derive  the 
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Figure  9:  The  Converter  Conversion  Model 

correct  protocol  converter  and  the  information  from  a  synchronizing  transition  set,  demonstrates  how  the 


the  implementation  must  be  included.  Nevertheless, 
M  tells  us  that  the  transitions  OUT  and  REG  need  to 
be  synchronized  and  this  is  what  the  next  step  of  the 
algorithm  is  for. 

3.3  Step  3:  Generate  the  Synchroniz¬ 
ing  Transition  Sets 

The  goal  of  this  step  is  to  derive  the  synchronizing 
transition  sets  from  the  conversion  service  specifica¬ 
tion  M  obtained  in  Step  2.  A  synchronizing  transition 
set  contains  the  transitions  which  must  be  executed 
together  (in  both  P*  and  Qa)  for  the  protocol  system 
to  correctly  perform  the  conversion  as  requested  by  the 
service  requirement  R.  For  ease  in  discussion,  the  tran¬ 
sitions  in  a  synchronizing  transition  set  is  called  the 
synchronizing  transitions.  Essentially,  the  idea  befind 
this  step  is  to  identify  the  aforementioned  synchroniz¬ 
ing  transitions  and  make  them  executed  together  such 
that  the  other  transitions  before  and  after  them  in 
both  protocol  entities  Pt  and  Qa  can  be  executed  syn¬ 
chronously.  Fig.  12,  in  which  tj  and  are  members  of 


synchronizing  transitions  tj  and  tk  synchronize  the  ex¬ 
ecution  of  the  transitions  in  protocol  entities  P&  and 
Qa. 

As  shown  in  Fig.  12,  when  Pi,  and  Qa  are  forced  to 
execute  tj  and  tjt  at  the  same  time,  all  the  transitions 
tfji^s  that  are  executable  only  after  tj  in  Pi,  should 
not  be  executed  before  tk  in  Qa  is  executed.  For  the 
same  reason,  the  execution  of  the  transitions  tn^s  in 
Qa  (which  are  executable  only  after  tk)  is  synchronized 
with  that  of /j  in  Pi,.  Consequently,  the  execution  of 
the  transitions  ^^’s  (tv's)  is  synchronized  with  that  of 
tn^  (^n’s)  which  belong  to  a  different  entity.  Note 
that  tm,  tny  tu  and  ty  are  as  shown  in  Fig.  12. 

The  complete  formal  procedure  to  generate  the  syn¬ 
chronizing  transition  sets  is  given  in  Appendix  of  the 
paper.  In  this  sub-section,  the  essential  steps  for  the 
generation  of  the  synchronizing  transition  sets  from  M 
is  briefly  described:  first,  all  the  legal  paths  pj’s  of  M 
are  generated,  where  a  legal  path  of  M  is  a  sequence  of 
service  transitions  which  starts  from  the  initial  state 
of  M  and  ends  also  at  the  initial  state;  if  any  two 
paths,  Pi  and  pj,  are  two  different  permutations  of 


Coordinated  Execution 

Figure  12:  Concurrent  Execution  with  Coordination  of  tj  and  tk 


each  other  (i.e.  different  ordering  of  the  same  tran¬ 
sitions),  a  synchronizing  transition  set  Sk  containing 
all  the  transitions  of  p,-  (pj)  is  then  created;  repeat 
the  process  until  all  possible  p,-  and  5^.’s  are  found 
(i.e.  each  possible  ordering  of  the  transitions  in  T>\{  is 
covered  by  at  least  one  p*).  Note  that  for  two  paths 
pi  and  pj  to  be  different  permutations  of  each  other, 
they  must  have  the  same  length  and  contain  exactly 
the  same  transitions;  e.g.  if  p,-  contains  4  fi’s  and  3 
t2^Sy  Pj  must  contain  the  same  numbers  of  <i’s  and 
^2^8,  where  ii  and  <2  are  different  transitions. 

The  application  of  this  procedure  to  the  example  is 
given  as  follows.  Note  that  the  aforementioned  syn¬ 
chronizing  transition  set  is  formally  defined  in  Ap¬ 
pendix.  The  legal  paths  of  M  are  generated  as  follows: 

1.  Pi  =  (OUT.REC)* 

2.  p2  =  (REC.OUT)* 

3.  P3  =  REC.(REC.OUT)*.OUT 

The  transition  sets  for  each  path  respectively  are  as 
follows: 

1.  Ti  =  {  REC,  OUT  } 

2.  r2  =  {  REC,  OUT  } 

3.  Ta  =  {  REC,  OUT  } 

Following  the  definition  of  a  synchronizing  transi¬ 
tion  set  given  in  Appendix,  it  is  clear  that  Ti  (To)  is  a 


synchronizing  transition  set  since  Ti  and  T2  are  equal 
sets,  and  pi  and  po  are  different  permutations  of  each 
other.  Thus,  the  synchronizing  transition  set  Si  can 
be  identified  as  follows: 

{  REC,  OUT  } 

Since  pi  and  po  cover  all  the  possible  ordering  (either 
an  OUT  before  a  REC  or  the  reverse)  of  all  the  tran¬ 
sitions  in  Em  (REC  and  OUT),  there  is  no  need  to 
proceed  further;  i.e.  there  is  no  need  to  check  on  T3. 
Note  that  in  this  example,  T3  happens  to  be  the  same 
synchronizing  transition  set  as  well.  In  addition,  it  is 
not  true  that  every  transition  set  found  in  this  step  is 
always  a  synchronizing  transition  set.  The  transition 
set  Ti  obtained  in  the  example  in  Section  4  is  not  a 
synchronizing  transition  set. 

One  may  argue  that  it  is  so  trivial  that  REC  and 
OUT  should  be  synchronized  and  this  step  of  the  algo¬ 
rithm  is  redundant.  This  may  ne  true  for  this  particu¬ 
lar  example,  in  which  there  is  only  one  service  transi¬ 
tion  in  each  of  Pb  and  Qa  (hence  only  2  different  tran¬ 
sitions  in  M);  therefore,  there  is  at  most  one  synchro¬ 
nizing  transition  set,  and  these  2  transitions  are  both 
in  the  synchronizing  transition  set.  However,  in  situ¬ 
ations  in  which  there  are  more  service  transitions  in 
M  (for  complex  protocols),  finding  the  synchronizing 
transition  set  is  not  always  trivial,  and  a  formal  pro¬ 
cedure  to  generate  the  synchronizing  transition  sets  is 
needed,  as  given  in  Appendix.  An  example  to  illus¬ 
trate  this  situation  is  shown  in  Section  4. 
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3.4  Step  4:  Compose  the  Converter 
Using  the  Coordinated  Composi¬ 
tion  Operation 

In  this  step  the  coordinated  composition  operation,  0, 
is  used  to  derive  the  converter,  using  the  synchronizing 
transition  sets  obtained  in  Step  3  as  the  synchronizing 
mechanism.  This  is  also  the  step  in  which  information 
from  the  protocol  implementation  is  involved  in  the 
construction  of  the  converter.  The  idea  of  this  step  is 
to  let  protocol  entities  and  Qa  execute  concurrently 
and  coordinatedly.  As  depicted  in  Fig.  12,  when  the 
coordinated  composition  operation,  O,  is  applied  to 
the  protocol  specifications  of  Ph  and  Qa,  protocol  en¬ 
tities  P^  and  Qa  are  forced  to  execute  the  transitions 
in  synchronizing  transition  sets  together  and  the  co¬ 
ordination/synchronization  between  transitions  in  Pt, 
and  Qa  is  achieved. 

In  this  example,  there  is  only  one  .synchronizing 
transition  set  Si.  For  ease  in  discussion,  a  new  tran¬ 
sition  Vi  for  Si  is  created,  such  that  the  execution  of 
Vi  in  both  P^,  and  Qa  means  the  execution  of  all  the 
transitions  in  Si  (i.e.  REC  and  OUT)  at  the  same 
time.  That  is,  Vi  is  to  be  incorporated  into  the  con¬ 
verter  by  the  ©  operation.  The  new  transition  V'l  is 
called  the  virtual  atomic  transition,  and  the  following 
can  be  established: 

virtual  atomic  transition  Vi  with 
5i  =  {  REC,  OUT  } 
and 

converter  C  ^  Py  ©  Qa 

The  operation  0  is  defined  as  follows. 

Definition  6.  Coordinated  Composition 
Operation  0. 

The  converter  C  =  Pt,  ©  Qa,  with  the  vir¬ 
tual  atomic  transition  Vi  and  the  correspond¬ 
ing  synchronizing  transition  set  5,  obtained 
in  Step  3,  where  i  =  1,  2,  is  a  six-tuple 
(^,E,  A,(5,  z,/),  where 

1.  ^  is  the  set  of  states  in  C  and 

g  =  {[u,  v]|  u,  V  are  states  of  and 
Qa  respectively  } 

2.  E  is  the  finite  set  of  service  transitions 
in  C  and 

E  =  Ep,UEg^U{  ally’s} 

(The  service  transition  set  in  C  will  be¬ 
come  empty  when  all  the  service  and 


virtual  atomic  transitions  are  removed 
from  the  final  converter  at  the  last  step 
of  the  algorithm  in  Section  3.5) 

3.  A  is  the  finite  set  of  peer  transitions  and 

A  =  Ap^  U  Aq^ 

4.  b  is  the  transition  function  of  C  and 
6([u,  v],  t)  = 

(a)  [u\  v]  if  t  G  Ap^  &  (5p^(u,  t)  =  u’ 

(b)  [u,  v’]  if  t  eXQ,  ^  bq^  (v,  t)  =  v’ 

(c)  [u’,  v]  if  t  G  Epj,  k  i  ^  any  of  the 

Si's  k  bp^{u,  t)  =  u' 

(d)  [u,  v']  if  t  G  Eo  k  i  ^  any  of  the 

(e)  [w  v’]  if  t  is  a  virtual  atomic  tran- 

si  ©Ui, 

A  ^u,  t’)  =  u’,  where  t’  G  Ep^ 

a:  ©  G 

t”)  =  vA  where  t”  G  Eg^ 
and  t”  G  Si . 

(In  this  example,  t’  =  OUT  and  t” 

=  REC) 

(f)  t  is  not  executable  at  state  [u,  v]  in 
C  if  none  of  the  above  is  true. 

5.  i  is  the  initial  state  of  C  and  i  = 
[zp^jZg^],  where  ip^  and  iq^  are  the  ini¬ 
tial  states  of  Pt,  and  Qa,  respectively. 

6.  /  is  the  .set  of  the  final  states  in  C  and 
/  =  {[/n./gJ}  {=  {[*>». *qJ}) 

The  result  of  applying  the  0  operation  to  P^  and  Qa 
to  obtain  the  Converter  C  is  shown  in  Fig.  13. 

The  0  operation  allows  all  the  transitions  in  Pt 
and  Qa  to  execute  concurrently  in  the  sequence  as 
the  original  protocols  prescribed,  as  long  as  the  transi¬ 
tions  are  not  synchronizing  transitions  (i.e.  transitions 
which  do  not  belong  to  a  synchronizing  transition  set). 
The  synchronizing  transitions  in  one  entity  have  their 
chance  of  e.xecution  when  the  peer  entity  is  ready  to 
execute  the  corresponding  synchronizing  transitions  in 
the  same  synchronizing  transition  set.  In  other  words, 
one  entity  must  wait  for  its  peer  to  execute  together 
the  synchronizing  transitions  in  a  synchronizing  tran¬ 
sition  set.  Note  that  a  synchronizing  transition  set 
always  contains  transitions  from  both  peer  entities. 
As  show;  in  Fig.  13,  at  state  [1,  1],  Qa  must  wait 
for  P^  to  get  to  state  2  before  executing  REC  (1©); 
i.e.  at  state  [2,  1]  of  C,  Pt  (in  state  2)  is  ready  to 
execute  OUT  and  Qa  (in  state  1)  is  ready  to  execute 


14 


Figure  13:  The  Converter  C 


REC,  and  both  OUT  and  REC  belong  to  the  synchro¬ 
nizing  transition  set  Si .  The  waiting,  however,  does 
not  change  the  ordering  of  the  transition  executions 
as  prescribed  in  the  original  and  Qa-  In  addition, 
none  of  the  transitions  is  thrown  away  by  the  O  oper¬ 
ation.  As  a  result,  the  properties  and  functionalities 
of  the  original  protocols  are  preserved. 

3-5  Step  5:  Remove  the  remaining  ser¬ 
vice  transitions 

This  is  the  final  step  to  derive  the  protocol  converter. 
The  converter  obtained  in  Step  4  contains  both  service 
and  virtual  atomic  transitions.  Recall  that  there  are 
no  service  users  on  top  of  the  converter;  therefore,  all 


the  service  transitions  must  be  changed  to  null  transi¬ 
tions  and  then  removed  from  the  final  converter  using 
the  algorithm  described  in  [22].  Moreover,  in  this  ex¬ 
ample,  the  virtual  atomic  transition  Vi  must  also  be 
removed  since  the  execution  of  Vi  means  the  execu¬ 
tion  of  service  transitions  only,  i.e,  OUT  and  REC. 
The  resulting  final  converter  specification  is  shown  in 
Fig.  14.  Note  that  the  same  technique  described  in 
Section  3.2  can  be  used  to  remove  the  null  transitions 
(which  are  service  transitions  and  virtual  atomic  tran¬ 
sitions  in  this  example). 

To  conclude  this  example,  let  us  see  what  has  been 
achieved  during  the  construction.  Notice  that  the  be¬ 
havior  of  either  P^  or  Qa  has  not  been  changed.  In- 
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Figure  14:  The  Final  Converter  of  Example  1 


stead,  the  execution  order  of  the  transitions  between 
Pt,  and  Qa  hcis  been  forced  in  accordance  with  the 
conversion  service  requirement,  R  (hence  also  M).  All 
transition  sequences  accepted  by  {Qa)  are  also  ac¬ 
cepted  by  the  converter  and  vice  versa  (in  terms  of 
the  projection  of  the  legal  paths  of  the  final  converter 
specification)  while  the  service  transitions  are  consid¬ 
ered  null  transitions  in  the  converter.  Therefore,  the 
properties  and  functionalities  of  the  original  protocols 
are  preserved  and  the  three  properties  for  correctness 
are  satisfied  with  no  need  for  an  additional  validation 
phase. 

4  A  More  Complex  Example 

In  this  section,  a  more  complex  example  is  presented 
to  demonstrate  that  finding  the  synchronizing  transi¬ 
tion  sets  is  not  always  trivial  and  a  formal  procedure 
in  Step  3  of  the  proposed  algorithm  is  needed.  Also 
presented  in  this  section  are  some  strategies  that  can 
be  used  to  reduce  the  complexity  in  Step  3  and  Step  4 
of  the  algorithm.  Moreover,  the  synchronizing  transi¬ 
tion  set  in  this  example  has  more  than  2  transitions; 
therefore,  the  virtual  atomic  transition  must  be  ex¬ 
panded  into  a  sequence  of  peer  transitions  at  the  last 
step  (Step  5)  of  the  converter  construction  process  in¬ 
stead  of  just  removing  it. 

Fig.  15  shows  the  given  protocol  specifications  of  P 


and  Q,  in  which  the  service  transitions  are  labeled  in 
capital  letters.  Protocol  P  is  a  simplified  flow  control 
protocol.  Before  sending  each  data  from  Pa  to  Pt,  a 
reservation  needs  to  be  confirmed.  If  P(,  has  no  space 
available  to  receive  data,  it  can  send  a  choke  message 
to  Pa  to  stop  the  sending.  Protocol  Q  is  a  simple  non¬ 
sequence  protocol  as  in  the  previous  example.  The 
service  specifications,  Pg,  Qs,  and  the  conversion  re¬ 
quirement  R  are  as  shown  in  Fig.  16. 

The  result  of  applying  the  (g)  and  |  operations  to  P,, 
R  and  Qg  to  obtain  the  conversion  service  specification 
M  at  Step  2  of  the  algorithm  is  shown  in  Fig.  17. 

Following  the  procedure  outlined  in  Appendix  for 
Step  3,  a  legal  path  can  be  obtained  as  follows: 

Pi  =  REQ.FULL 

(and  the  transition  set  Ti  =  {REQ,  FULL}) 

where  pi  contains  transitions  from  Pi,  only,  which 
means  that  the  transitions  (REQ  and  FULL)  in  pi 
have  nothing  to  do  with  the  synchronization  between 
protocols  P  and  Q;  thus,  REQ  and  FULL  can  be  re¬ 
moved  from  M.  The  simplified  M  is  shown  in  Fig.  18, 
where  states  [2,  2,  1]  and  [3,  2,  2]  are  removed.  Note 
that,  as  M  becomes  smaller,  so  does  the  complexity  of 
this  step  (Step  3)  in  the  generation  of  synchronizing 
transition  sets.  For  the  same  reason  and  from  the  fact 
that  there  are  no  service  users  on  top  of  the  converter, 
REQ  and  FULL  can  also  be  removed  from  the  original 
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Figure  15:  The  Given  Protocols  P  and  Q  of  Example  2 


protocol  specification  Ph  in  Fig.  15  (before  composi¬ 
tion  of  the  final  converter  at  Step  4).  The  simplified 
Pb  is  shown  in  Fig.  19,  where  REQ  and  FULL  are  re¬ 
moved  from  Pb  and  only  service  transitions  OK  and 
OUT  remain  in  Pb  (as  the  synchronizing  mechanism) 
for  the  next  step  (Step  4)  of  the  algorithm.  With  the 
simplified  protocol  specification  of  Pb  as  an  operand 
of  the  coordinated  composition  operation  ©,  the  com¬ 
plexity  of  Step  4  can  also  be  reduced. 

Following  through  the  procedure  in  Step  3  of  Ap¬ 
pendix,  a  synchronizing  transition  set  5i  =  {OK, 
OUT,  REC}  is  obtained.  Note  that  in  Si,  OK  and 
OUT  belong  to  Pb  and  REC  belongs  to  Qa-  This 
means  one  service  transition  of  Qa,  REC,  must  be 
synchronized  with  two  service  transitions  of  Pb,  OK 
and  OUT.  Thus,  a  virtual  atomic  transition  Vi  for  Si 
can  be  created.  The  meaning  of  the  execution  of  Vi  in 
this  example  is  quite  different  from  that  in  Example  1, 
since,  by  definition,  the  execution  of  Vi  (in  this  exam¬ 
ple)  means  execution  of  more  than  just  one  transition 
from  each  peer  protocol  entity  (OK  and  OUT  in  Pb 
and  REC  in  Qa).  Following  the  protocol  specification 
of  Pb  in  Fig.  19,  it  is  easy  to  see  that  a  sequence  of 
transitions  that  execute  both  OK  and  OUT  from  Pb 
is: 

=  OK.-conf.-fdata.OUT 

In  other  words,  to  execute  both  OK  and  OUT  together 
with  REC  in  a  sequence  of  transitions  must 
be  executed  atomically.  To  be  more  specific,  the  ex¬ 


ecution  of  Vi  means  the  execution  of  both  in  Pb 
and  REC  in  Qa  atomically.  Thus,  the  meaning  of  the 
execution  of  a  virtual  atomic  transition  is  extended 
(to  cover  the  execution  of  a  sequence  of  transitions), 
and  the  definition  of  the  coordinated  composition  op¬ 
eration  0  can  be  refined  accordingly  as  follows: 

Definition  7.  Refined  Coordinated  Compo¬ 
sition  Operation  ©. 

The  converter  C  —  PbOQa,  with  the  virtual 
atomic  transition  Vi,  the  corresponding  syn¬ 
chronizing  transition  set  Si  and  a  legal  path 
Pi  (from  the  conversion  service  specification 
M)  obtained  in  Step  3,  where  i  =  1,2,  ...,  is 
a  six-tuple  {q,  E,  A,  6,  i;f),  where: 

1.  q  is  the  set  of  states  in  C  and 

^  {[u,  v]|  u,  V  are  states  of  Pb  and 

Qa,  respectively  } 

2.  E  is  the  finite  set  of  service  transitions 
in  C  and 

E  =  Ep,UEg,  U{all  V;’s} 

(Again,  the  service  transition  set  E  will 
become  empty  at  the  last  step  (Step  5)) 

3.  A  is  the  finite  set  of  peer  transitions  and 

X  =  Xp^U  Xq^ 

4.  (5  is  the  transition  function  of  C  and 
6([u,  v],  t)  = 


Figure  16:  The  Conversion  Service  Requirement  and  the  Service  Specifications 


(a)  [u’,  v]  if  t  E  Ap^  &  t)  =:  u’ 

(b)  [u,  v’]  if  t  e  Xq,  t  <5q,(v,  t)  =  v’ 

(c)  [u’,  v]  if  t  E  Sp^  &  t  ^  any  of  the 
Si's  &  Sp^{u,  t)  =  u’ 

(d)  [u,  v’]  if  t  E  &  t  ^  any  of  the 

Si's  k  t)  =  v’ 

(e)  [u’,  v’]  if  t  is  a  virtual  atomic  tran¬ 
sition,  Vi, 

k  ^pj,(u,  /9pJ  =  u\  where  6*p^ 
means  applying  6p^  to  a  sequence 
of  transitions  and  pp^  is  a  legal  se¬ 
quence  of  transitions  in  Pi,,  which 
starts  and  ends  with  service  tran¬ 
sitions  that  are  members  of  5*  and 
|SP4=  Isp^ 

^  PQ.)  =  v’,  where  Sq^ 

means  applying  6q^  to  a  sequence 
of  transitions  and  is  a  legal  se¬ 
quence  of  transitions  in  Qa,  which 
starts  and  ends  with  service  tran¬ 
sitions  that  are  members  of  F  "id 

PQ.  ISq,  =  Pi  ISg, 

[pp^  =  OK.-conf.-f-data.OUT 
and  pQ^  =  REC  for  Vx  in  Exam¬ 
ple  2) 

Note  that  a  legal  sequence  of  tran¬ 
sitions  of  a  CFSM  is  a  sub-sequence 
of  a  legal  path  of  the  CFSM. 

(f)  t  is  not  executable  at  state  [u,  v]  in 


C  if  none  of  the  above  conditions  is 
true. 

5.  t  is  the  initial  state  of  C  and  i  =■ 
[/'p^,2q^],  where  ip^  and  iq^  are  the  ini¬ 
tial  states  of  Pfi  and  Qa,  respectively. 

6.  /  is  the  set  of  the  final  states  in  C  and 

/  =  {[fp.’fQ.]}  i=  *<?.]})• 

The  result  of  applying  the  refined  coordinated  com¬ 
position  operation  to  protocol  entities  P&  and  Qa  to 
obtain  the  converter  is  shown  in  Fig.  20.  Note  that 
the  simplified  protocol  specification  of  P&  in  Fig.  19  is 
used  in  this  step  to  reduce  the  complexity. 

In  this  example,  a  sequence  of  transitions  from  one 
protocol  entity  is  converted  into  a  transition  in  an¬ 
other.  In  other  words,  using  the  refined  coordinated 
composition  operation  defined  above,  it  is  possible  to 
perform  the  protocol  conversion  between  sequences  of 
transitions  in  different  protocols.  This  is  a  very  en¬ 
couraging  result  of  the  proposed  algorithm  since  many 
of  the  existing  conversion  algorithms  can  only  han¬ 
dle  mapping  between  single  transition/message  (i.e. 
one-to-one  conversion  in  terms  of  either  transitions  or 
messages),  and  the  semantics  of  a  sequence  of  transi¬ 
tions/messages  can  be  different  from  that  of  a  simple 
concatenation  of  the  semantics  of  each  original  indi¬ 
vidual  transition/message  for  complex  protocols.  It 
is  our  observation  that  a  conversion  algorithm  capa¬ 
ble  of  handling  conversion  between  sequences  of  tran¬ 
sitions  is  more  powerful  and  practi^  when  dealing 


Figure  17:  The  Conversion  Service  Specification  M  of  Example  2 


Figure  18:  The  Simplified  Conversion  Service  Specification  M  of  Example  2 


with  complex  protocols.  Moreover,  note  that  the  new 
transition  Vi  has  become  a  virtual  atomic  transition 
in  the  sense  that  when  Vi  is  executed  all  transitions  in 
both  (a  sequence  of  transitions)  and  pq^  are  exe¬ 
cuted  atomically.  Also  note  that  Vi's  execution  means 
not  only  execution  of  service  transitions  but  also  some 
peer  transitions  (-conf.-fdata).  Therefore,  Vi  must  be 
expanded  to  incorporate  the  peer  transitions  from  pp^^ 
in  the  final  converter  specification.  The  final  converter 
is  shown  in  Fig.  21.  Note  that  a  dummy  state,  D,  is 
created  for  the  expansion  of  the  virtual  atomic  tran¬ 
sition  Vi, 


5  Formal  Proof  of  Correctness 

In  this  section  a  formal  proof  is  presented  to  show  that 
the  proposed  algorithm  always  constructs  a  converter 


that  satisfys  the  three  properties  of  a  correct  converter 
as  defined  in  Definition  3  of  Section  2. 

For  the  transparency  property,  it  is  easy  to  see  that 
the  protocol  entities  at  the  end  nodes  (Pa  and  Qb) 
of  the  composed  protocol  system  are  not  altered  dur¬ 
ing  the  converter  construction;  therefore,  the  trans¬ 
parency  property  is  indeed  satisfied.  In  addition,  the 
liveness  and  conformity  properties  are  satisfied  (with¬ 
out  the  need  of  a  validation  phase)  since  all  the  prop¬ 
erties  and  functionalities  from  the  original  protocol 
entities  are  preserved  during  the  derivation  of  the  con¬ 
verter.  Intuitively,  since  all  the  properties  and  func¬ 
tionalities  are  preserved  and  inherited  by  the  con¬ 
verter,  it  will  have  the  same  properties  and  perform 
the  same  functions  as  the  original  protocols  do.  In 
other  words,  it  will  inherit  the  liveness  property  if 
the  original  protocols  do  have  the  liveness  property. 
Similarly,  it  will  also  inherit  all  the  functionalities  of 
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Figure  19:  The  Simplified  Protocol  Specification  Ph  of  Example  2 


the  original  protocols  and  hence  satisfy  the  conformity 
property.  Formally,  the  rest  of  this  section  shows  a  for- 
mal  proof  of  the  following  statement:  the  liveness  and 
conformity  properties  are  preserved  by  the  converter 
and  an  additional  validation  phause  is  not  required. 

5.1  Liveness  Property 

As  mentioned  in  Section  2,  the  liveness  property  of 
a  protocol  converter  means  that  the  composed  proto¬ 
col  system,  Pa,  C,  and  Qb,  is  deadlock/livelock  free. 
Formally,  the  liveness  property  between  three  protocol 
entities  is  defined  in  Definition  8  as  follows. 

Definition  8.  Liveness  property  among 
three  protocol  entities. 

In  a  composed  protocol  system  of  C  and 
Qb,  where  Pa  and  Qb  are  protocol  entities  at 
the  end  nodes  and  C  is  the  converter  between 
them,  if  it  is  deadlock/livelock  free  between 


Pa  and  C  and  between  C  and  Qb,  the  con¬ 
verter  C  (akso  the  composed  protocol  system) 
is  said  to  have  the  liveness  property. 

The  goal  of  this  subsection  is  to  prove  that  the  con¬ 
verter  constructed  by  the  proposed  algorithm  does 
have  the  liveness  property,  and  the  following  definition 
of  a  live  converter  will  be  used  in  the  formal  proof. 

Definition  9.  A  live  converter  for  protocol 
P  and  Q. 

A  converter  C  is  a  live  converter  iff  the  fol¬ 
lowing  is  true: 

V  a  path  7  in  C,  where 

i5c([*>»-*q.]-7)  =  ^]> 

(i.e.  7  starts  from  the  initial  state  [ip^,  t<j„] 
and  ends  at  a  state  [u,  v]) 

3  paths  T  of  Pb  and  uj  Qa  3 

7  Up,=  r  Up,  &  =  « 

and 
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+ack 


7  |Ag„  =  W  |Ag„  &  6’q^  [iq,  ,  w)  =  V 

Note  that  a  path  in  this  paper  is  a  transition 
sequence  which  starts  from  the  initial  state 
of  the  CFSM  and  [zp^ ,  iq^]  is  the  initial  state 
of  C  (zpb  and  iq^  are  the  initial  states  of  Pj 
and  Qa^  respectively).  6'"  means  applying 
6  to  a  sequence  of  transitions  as  defined  in 
Definition  7, 

Next,  it  is  shown  in  Lemma  1  that  a  live  converter 
has  the  liveness  property  if  the  original  protocols  P 
and  Q  are  deadlock/livelock  free  and  in  Lemma  2,  the 
converter  constructed  by  the  proposed  algorithm  is 
proved  to  be  a  live  converter. 

Lemma  1.  A  live  converter  C  has  the  live¬ 
ness  property  if  both  P  and  Q  have  the  live¬ 
ness  property. 

Given: 

1.  P  and  Q  are  deadlock  and  livelock  free. 

2,  C  is  a  live  converter. 

Need  to  Prove: 

It  is  contradictory  to  the  given  conditions  if 
C  does  not  have  the  liveness  property. 

Proof: 


entities  C,  Pa  and  Q*  reach  a  dead¬ 
lock/livelock  state  among  them  (either 
between  Pa  and  C  or  between  C  and 
Qt) 

(Since  C  is  a  live  converter)  3  paths  r 
of  Pb  and  w  of  Qa,  where: 

1  Uq, 

9  when  a,  r,  w,  /?  are  executed  at 
Pay  Pby  Qa  and  Qh  respectively,  dead¬ 
lock/livelock  is  resulted  between  either 
Pa  and  Pb  or  Qa  and  Qb 

=>  Either  P  or  Q  is  not  deadlock/livelock 
free 

In  contradiction  to  the  given  condition 

1 

In  Lemma  2,  the  induction  method  on  the  length  of 
the  transitions  accepted  by  protocol  entities  is  used  to 
prove  that  the  converter  C'  constructed  at  Step  4  is  a 
live  converter.  Note  that  the  converter  constructed  at 
Step  4  contains  service  transitions  which  are  eventu¬ 
ally  removed  at  Step  5  of  the  algorithm. 


=>  Assume  C  does  not  have  the  liveness 
property 

3  a  path  7  of  C  9 

when  7  is  executed  at  C,  the  entities 
C,  Pa  and  Qb  reach  a  deadlock/livelock 
state  among  them 

=>  3  paths  7  of  C,  a  of  Pa,  /?  of  Qb  9 

when  7,  Q  and  /?  are  executed  the 


Lemma  2,  The  converter  C'  constructed  at 
Step  4  is  a  live  converter;  i.e. 


V  a  path  7  of  C',  where 

iQ.]<  7)  =  [w.  t']. 

3  paths  r 

of  Pb  and  w  of  Qa  9 

7Up,=  'r 

Up,  &  6pS^P,,r)  =  u 

and 

7  |Ag,=  w  1 

^Qa  ^  ' 

Base: 

It  is  true  for  7  of  length  0 

Induction  Hypothesis: 

Assume  it  is  true  for  all  7’s  of  length  up  to 

m 

Need  to  Prove: 

It  is  true  for  7'  of  length  m+1 

Proof: 

=>  (From  the  induction  hypothesis) 

V  7  of  length  m,  3  paths  r  of  and  uj 

of  Qa  9 

7  Up,=  r  Iap^  =  ti-U  -ti 

k 

Uq.  =  Si.S2...Sn, 

where  ^1,^2.  •••  ^ 

Si  ,  S2,  ...  ,Sn  G  Aq^  ; 

<5c'([*Pw  »Q.].  7)  =  [w-  1']  aiid 

t)  =  “and^^JiQ. ,  a))  =  V 

(i.e.  after  execution  of  7,  C'  is  at  state 
[u,  v];  after  r,  Pt,  is  at  state  u,  and  after 
uf,  Qa  is  at  state  v) 

=>  Let  y  =  j.t  be  a  path  of  length  m-f  1 
and  t  is  executable  at  state  [u,  v]  in  con¬ 
verter  C': 

By  definition  (Item  4  of  Definition  7 
in  Section  4),  t  can  be  either  a  virtual 
atomic  transition  or  a  peer/service  tran¬ 
sition  of  Pi,  or  Qa-  If  t  is  a  virtual 
atomic  transition,  it  can  be  expanded 
into  a  sequence  of  normal  service/peer 
transitions  (i.e.  into  the  p  defined  in 
Item  4.e  of  Definition  7)  without  chang¬ 
ing  the  behavior  of  C'.  Thus,  without 
loss  of  generality,  t  only  needs  to  be 
considered  as  a  normal  transition  of  the 
original  protocol  entities  Pb/Qa- 
1.  If  t  G  Ap^,  then,  by  Item  4. a  of  Def¬ 
inition  7: 

Sc'{[u,  i;],  t)  =  [i/',  v]  and 

i)  = 

^Qa].  7-0  = 

and  6p^{ip,,  r.t)  =  u' 

7^1  Up^  =  (7  |Ap^ 

).jf  —  1 1  .to  -  -  -  tl  -  t  —  |ap^ 

)^t  =  r.t  Iap^ 

— ^  y.i  |ap^  =  r.t  Iap^ 

(in  this  case,  j.t  |aq^  does  not 
change  and  it  is  still  equal  to 

UqJ 


Similarly,  by  Item  4.b  of  Defini- 


tion  7,  if  t 

7-1  Iaq^ 

=  Uq. 

(7-<  Up*  is 

still  equal  to  r 

Un  i" 

this  case) 

Ift  G  Sp,  1 

:hen  by  Item  4.c 

of  Def- 

inition  7: 

<5c'([w. 

v],  t)  =  [u', 

1;]  and 

Sp^(u,  t)  ~ 

u' 

.  *(?,].  7-0  = 

[u',  i;] 

and  (5p,(ip* 

,  T.t)  =  U' 

— ^  7'^  Up*  ■ 

M 

_ 

II 

Pb 

Up*  ^ 

”  ^  1 A 

4.  Similarly,  by  Item  4.d  of  Defini¬ 
tion  7,  if  t  G  : 

^  7'^  Uq^  —  ^  |aq^ 

=>  For  7'  =  j.t  of  length  m-fl,  where 

<5c([*n>  »<?.]'  t')  =  [«"-  t'"]. 

3  paths  P  of  Pb  and  lj'  of  Qa  3 

7'  Up,=  r'  Up,  = 

and 

7'  U<3,=  w'Uq.  (*■(?..  w')  =  v" 

Depending  upon  whether  t  is  a  peer  or 
service  transition  of  Pb,  P  can  be  either 
r.t  or  T  and  iP  can  be  either  u'  or  u. 

The  same  is  true  for  cj'  and  t?". 

=>  It  is  true  for  path  7^  of  length  m-fl. 

From  Lemma  1  and  Lemma  2,  it  is  easy  to  see  that 
the  converter  C'  constructed  at  Step  4  has  the  live¬ 
ness  property  if  the  original  protocols  P  and  Q  have 
the  liveness  property.  Since  there  are  no  service  users 
on  top  of  the  converter,  the  service  transitions  in  C'  do 
not  serve  any  functions.  Therefore,  removing  the  ser¬ 
vice  transitions  from  to  obtain  the  final  converter 
C  at  Step  5  does  not  change  the  functionalities  and 
properties  of  the  converter.  In  other  words,  the  final 
converter  does  have  the  liveness  property  if  both  P 
and  Q  have  the  liveness  property. 

Theorem  1.  The  converter  C  constructed 
by  the  proposed  algorithm  has  the  liveness 
property  if  the  original  protocols  P  and  Q 
have  the  liveness  property. 

Proof: 

Trivial  from  Lemma  1  and  Lemma  2  above. 

5.2  Conformity  Property 

For  proof  of  the  conformity  property  in  this  subsec¬ 
tion,  the  strategy  is  first  to  show  that  the  converter 


Note  that  a  legal  path  is  a  path  which  ends 
at  the  initial  state  of  a  protocol  entity. 


constructed  by  the  algorithm  supports  no  more  func¬ 
tions  than  the  original  protocol  entities  Pb  and  Qa  do, 
and  then  to  prove  that  it  also  supports  no  less  func¬ 
tions. 

Lemma  3.  A  live  converter  C  supports  no 
more  functions  than  the  original  protocol  en¬ 
tities  Pb  and  Qa  do. 

Proof: 

=>  Since  C  is  a  live  converter: 

V  a  path  7  in  C,  3  paths  r  of  Pb  and  u; 
of  Qa  9 

7  |ap,=  t  k  7  U<3„  =  w  |a<5„ 

=>  The  function  supported  by  j  |ap^  is  sup¬ 
ported  by  T  in  Pb  and  the  function  sup¬ 
ported  by  7  is  supported  by  uj  in 
Qa 

=>  The  function  supported  by  a  legal  path 
of  C  can  be  supported  by  a  legal  path 
of  Pb  and  a  legal  path  of  Qa 

C  supports  no  more  functions  than  Pb 
and  Qa  do 

Since  it  has  been  proved  in  Section  5.1  that  the  con¬ 
verter  constructed  by  the  algorithm  is  a  live  converter, 
by  Lemma  3  above,  it  is  trivial  to  see  that  the  con¬ 
verter  supports  no  more  functions  than  the  original 
protocol  entities  Pb  and  Qa  do.  Thus,  the  following 
Lemma  has  been  proved: 

Lemma  4.  The  converter  C  constructed 
by  the  proposed  algorithm  supports  no  more 
functions  than  the  original  protocol  entities 
Pb  and  Qa  do. 

Proof: 

Trivial  from  Lemma  2  and  Lemma  3. 

Next,  it  is  shown  that  the  converter  constructed 
supports  no  less  functions  than  the  original  protocol 
entities  Pb  and  Qa  do.  The  following  definition  is  used 
in  the  proof. 

Definition  10.  A  conforming  converter  for 
protocol  P  and  Q: 

A  converter  C  is  a  conforming  converter  iff 
the  following  is  true: 

V  a  legal  path  r  of  Pb  (and  u  of  Qa),  3  71 
(and  3  72)  of  C  9 
T  T1  IApj, 

(and  u;  |aq^  =  72  ) 


In  Lemma  5  and  Lemma  6  below,  it  is  shown  that  a 
conforming  converter  supports  no  less  functions  than 
the  original  protocol  entities  do,  and  that  the  con¬ 
verter  constructed  by  the  proposed  algorithm  is  a  con¬ 
forming  converter. 

Lemma  5.  A  conforming  converter  C  sup¬ 
ports  no  less  functions  than  the  original  pro¬ 
tocol  entities  Pb  and  Qa  do. 

Proof: 

=>  C  is  a  conforming  converter  and  by  Def¬ 
inition  10: 

V  a  legal  path  r  of  Pb  (and  u  of  Qa),  3 
7i  (and  3  72)  of  C  9 
rUp,=  7i|Ap, 

(and  w  Iaq^  =  72  Up.  ) 

=>  The  function  supported  by  a  legal  path 
T  in  Pb  {u;  in  Qa)  is  supported  by  71 
(72)  in  C 

The  function  supported  by  a  legal  path 
r  (w)  in  Pb  (Qa)  can  be  supported  in  C 
by  a  legal  path  71  (72) 

=>  C  supports  no  less  functions  than  Pb 
(Qa)  does. 

Using  the  same  method  (induction  method)  as  in 
the  proof  of  Lemma  2  it  can  be  proved  that  the  con¬ 
verter  constructed  by  the  algorithm  is  indeed  a  con¬ 
forming  converter. 

Lemma  6.  The  converter  C'  constructed  in 
Step  4  is  a  conforming  converter. 

Proof: 

Since  the  proof  is  similar  to  that  of  Lemma  2 
(i.e.  the  induction  method),  it  is  not  re¬ 
peated  here. 

From  Lemma  4,  Lemma  5  and  Lemma  6,  it  is  easy 
to  see  that  the  converter  so  constructed  supports  no 
more  and  no  less  functions  than  the  original  protocol 
entities  Pb  and  Qa  do.  Thus,  the  following  Theorem  2 
is  easily  established. 
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Theorem  2.  The  converter  constructed  by 
the  proposed  algorithm  has  the  conformity 
property. 


As  a  result  of  Theorem  1  in  Section  5.1  and  Theo¬ 
rem  2  in  Section  5.2,  it  is  clear  now  that  the  proposed 
algorithm  will  always  generate  a  converter  with  the 
liveness  and  conformity  properties  without  an  addi¬ 
tional  validation  phase,  as  claimed  earlier. 

6  Conclusion 

The  work  presented  here  shows  how  to  derive  a  correct 
converter  formally  from  the  conversion  service  require¬ 
ment  and  the  service  specifications  given  by  the  service 
users,  by  using  the  operations,  ®,  |  and  O.  Follow¬ 
ing  the  ordering  of  the  transition  execution  sequences 
described  in  the  original  protocol  entities,  the  algo¬ 
rithm  uses  the  synchronizing  transition  sets  and  the 
virtual  atomic  transitions  as  the  synchronizing  mech¬ 
anism  to  derive  a  correct  converter.  The  behavior  of 
the  original  protocols  is  inherited  by  the  converter  con¬ 
structed  and  all  the  properties  and  functionalities  are 
preserved.  This  is  the  main  reason  why  the  proposed 
5-step  algorithm  can  satisfy  the  conformity  property 
of  a  correct  converter  without  an  additional  validation 
phase,  which  is  required  by  many  existing  algorithms 
based  on  the  service  specification  approach. 

The  service  specification  approach  is  adopted  in  this 
paper  because  it  is,  in  general,  easier  to  find  a  seman¬ 
tically  correct  conversion  service  requirement  than  to 
find  a  correct  conversion  specification  in  an  ad  hoc 
manner  by  directly  examining  the  implementation  of 
the  given  protocols.  Therefore,  the  service  specifi¬ 
cation  approach  is  more  practical  than  the  conver¬ 
sion  specification  approach  when  dealing  with  complex 
protocols. 

The  proposed  algorithm  always  finds  a  converter 
that  satisfies  the  given  conversion  service  requirement. 
If  the  requirement  given  is  semantically  correct,  so 
is  the  converter  constructed  without  a  need  for  val¬ 
idation  phase,  since  the  properties  and  functionalities 
of  the  given  conversion  service  requirement  are  inher¬ 
ited  by  the  converter.  In  addition,  in  Section  4  it  is 
demonstrated  that  the  algorithm  has  the  capability  of 
handling  conversion  between  sequences  of  transitions 
in  different  protocols.  This  capability  is  very  crucial 
when  dealing  with  complex  protocols  in  which  the  se¬ 
mantics  of  sequences  of  transitions/messages  is  differ¬ 
ent  from  that  of  a  simple  concatenation  of  the  seman¬ 
tics  of  each  original  individual  transition/message.  In 
other  words,  in  a  situation  where  simple  one-to-one 
transit  ion/ message  mapping  between  protocols  is  not 
sufficient  to  derive  a  correct  converter  and  the  conver¬ 


sion  can  only  be  done  in  a  unit  of  sequence  of  tran¬ 
sitions/messages,  the  proposed  algorithm  can  still  de¬ 
rive  a  correct  converter  succeesfully. 

The  complexity  of  the  proposed  algorithm  is  at 
worst  exponential  in  time  and  space  since  the  algo¬ 
rithm  of  removing  the  null  transitions  in  [22]  is  expo¬ 
nential.  However,  the  complexity  can  be  reduced  by 
the  method  described  in  Section  3.2  (i.e.  removal  of 
states  with  only  one  incoming  or  outgoing  null  transi¬ 
tion).  Areas  of  interest  for  future  work  include  reduc¬ 
ing  the  complexity  at  Step  3  of  the  algorithm.  That  is 
to  find  a  better  way  to  derive  the  synchronizing  tran¬ 
sition  sets  from  the  conversion  service  specification  M. 
In  addition,  a  formal  method  to  derive  the  semanti¬ 
cally  correct  conversion  service  requirement  from  the 
service  specifications  is  also  useful. 
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Appendix 

Outline  of  the  Algorithm 

Step  1.  Generate  the  Service  System  Graph  G: 

The  service  system  graph  is  obtained  by  applying 
the  modified  composition  operation,  0,  (defined 
in  Definition  4)  to  the  given  service  specifications, 
Ps  and  Qs  and  the  conversion  service  requirement 
R,  where  Ps^Qs  and  R  are  as  defined  in  Defi¬ 
nition  3  (the  Protocol  Conversion  Problem).  In 
short,  G  is  obtained  by 

G=<  Ps.R^Qs  >=  Ps0  R^Qs 

Step  2.  Derive  the  Conversion  Service  Specification 
M: 

M  is  derived  by  applying  the  projection  operation, 

I  (defined  in  Section  3.2),  to  G  as  follows. 

M  =  G 

where  and  Eq^  are  the  service  transition  sets 
of  Pi  and  Qa,  respectively. 

Step*  3.  Generate  the  Synchronizing  Transition  Sets: 
The  synchronizing  transition  sets  are  generated 
from  the  conversion  service  specification  M  ob¬ 
tained  in  Step  2. 

(a)  Generate  all  legal  paths  of  M,  where  a  le¬ 
gal  path,  Pi,  is  a  sequence  of  service  transi¬ 
tions  that  is  accepted  by  M.  In  other  w'ords, 
a  legal  path  is  a  sequence  of  service  tran¬ 
sitions  which  starts  from  the  initial  state 
of  M  and  tMids  also  at  the  initial  state. 
(Since  M  is  .  deterministic  CFSM,  the  algo¬ 
rithm  described  in  [22]  can  be  used  to  con¬ 
vert  the  CFSM  into  a  set  of  regular  expres¬ 
sions.  From  the  regular  expressions  obtained 
all  the  legal  paths  can  be  easily  generated) 
For  each  path  generated,  check  if  it  con¬ 
tains  transitions  from  only  one  entity  (i.e. 
either  from  P  or  Q  but  not  both).  If  so, 
the  transitions  in  the  path  have  nothing  to 
do  with  synchronization  between  protocols 
P  and  Q  and  can  be  removed  from  M  and 
from  all  the  other  paths  already  found.  In 
addition,  these  service  transitions  can  also 
be  removed  from  the  original  protocol  spec¬ 
ification  (Pi  and/or  Qa)  to  reduce  the  com¬ 
plexity  at  Step  4  of  the  propo.sed  algorithm. 


This  step  stops  when  all  the  relative  execu¬ 
tion  orders  of  the  transitions  in  M  are  repre¬ 
sented  by  at  least  one  legal  path  generated. 

(b)  For  each  path,  pi,  generated  in  (a),  create 
a  transition  set,  T,-,  whose  members  are  the 
transitions  in  the  path. 

Ti  =  {  t  I  t  is  a  transition  in  pi] 

(c)  For  each  transition  set  generated  in  (b),  use 
the  following  definition  to  identify  if  it  is  a 
synchronizing  transition  set  where  k  is 
an  arbitrary  number  used  to  distinguish  one 
synchronizing  transition  set  from  another. 

Definition  Synchronizing  Transi¬ 
tion  Set  S: 

A  transition  set  Tj  is  a  synchroniz¬ 
ing  transition  set  if  the  following  is 
true: 

3  j  i  3  Ti=Tj 
&  Pi  and  pj  are  two  different 
permutation  of  each  other. 

Note  that  T,-,  Tj ,  pi  and  pj  are  as  gener¬ 
ated  in  Step  (a)  and  Step  (b)  above.  The 
synchronizing  transition  set,  5jt,  represents 
a  set  of  service  transitions  that  must  be  syn¬ 
chronized  between  protocols  P  and  Q  to  per¬ 
form  the  functions  requested  by  conversion 
service  requirement  R. 

Step  4.  Compose  the  Converter  using  the  Synchro¬ 
nizing  Transition  Sets: 

For  each  synchronizing  transition  set  Sk  found  in 
Step  3,  create  a  virtual  atomic  transition  14.  Af¬ 
ter  all  such  Vic's  (from  all  Sk's  obtained  in  (c) 
above)  are  found,  the  converter  specification  is 
then  derived  by  applying  the  refined  coordinated 
composition  operation,  0,  defined  in  Definition  7, 
to  the  protocol  specifications  Pi  and  Qa  and  the 
14 ’s  created: 

converter  C  =  0  Qa 

Step  5.  Remove  the  service  transitions: 

From  the  converter  specification  C  obtained  at 
Step  4,  change  all  the  service  transitions  into  null 
transitions  and  then  use  the  algorithm  described 
in  [22]  to  remove  them  from  C.  If  a  virtual  atomic 
transition  introduced  at  Step  4  corresponds  to 
only  some  service  transitions  (as  in  Example  1), 
it  can  also  be  removed  immediately;  otherwise,  it 
must  be  expanded  into  a  sequence  of  peer  transi¬ 
tions  (as  in  Example  2). 
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Out  of  recently  proposed  high  speed  networks 
such  as  DQDB,  FDDf  ATM,  etc.,  various 
issues  have  been  examined  to  determine  the  most 
suitable  type  of  backbone  network  for  multimedia 
networksjl].  At  this  point  in  time,  evaluations 
are  still  inconclusive.  As  a  result,  different  high 
speed  networks  using  different  protocols  will  co¬ 
exist  in  an  integrated  multimedia  network  in  the 
near  future.  Like  the  traditional  heterogeneous 
data  networks,  the  inter-operability  aynong  the 
interconnected  heterogeneous  high  speed 
networks  will  be  the  key  to  success  for  integrated 
multimedia  networks.  On  the  other  hand,  unlike 
the  traditional  heterogeneous  data  networks,  a 
simulation  study  presented  in  this  paper  shows 
that,  due  to  the  special  characteristics  (e.g.,  high 
speed  and  high  connectivity)  of  these  integrated 
multimedia  networks,  the  traditional  protocol 
conversion  model  will  introduce  long 
transmission  delays  and  render  a  ndwork 
system  useless.  Thus,  in  addition  to  the 
simulation  study,  efforts  are  made  in  this  paper 
to  modify  the  previously  proposed 
Synchronizing  Transition  Set  (STS)[2} 
algorithm  to  accommodate  the  high  speed  and 
high  connectivity  of  a  multimedia  network  For 
the  modified  algorithm,  the  protocol 
compiensation  model  is  used  instead  of  the 
traditional  intermediate  conxferter  model  while 
all  the  desirable  strengths  of  the  original  STS 
approach  are  retained. 


1.  Introduction 

In  recent  years,  rapid  advance  in  network  technolo¬ 
gies  and  transmission  infrastructure,  using  optical  fiber, 
has  resulted  in  an  unprecedented  telecommunication 
exploration  of  integrated  multimedia  networks.  Tech¬ 
nologies  in  many  computer  science  areas  are  being 
explored  to  support  the  ever  growing  demands  of 
multimedia  applications  [3,4,5,6,7,8].  In  the  mean  time,  a 
variety  of  high  speed  networks,  such  as  ATM,  FDDI, 
and  E)QDB,  which  exhibit  speeds  in  the  range  of 
hundreds  of  Mbits /s  and  even  Gbits/s,  have  been 
proposed  as  the  potential  backbone  networks  for 
supporting  multimedia  applications.  So  far,  there  is  not 
one  network  from  the  proposed  lists  which  is  superior 
to  all  the  otf^ers  in  all  aspects.  For  example,  as  pointed 
out  in  [1],  to  achieve  better  resource  utilizatiem,  the 
bandwidth  allocation  at  a  multiplexing  point  in  an  ATM 
network  is  dynamic.  This  in  turn  facilitates  support  of 
bursty  traffic  types  of  multimedia  applications.  On  the 
other  hand,  an  FDDI  network  could  be  favored  for  non- 
bursty  transmission  of  voice  and  video  packets  due  to 
its  guarantees  of  bounded  access  delay.  Yet  under  light 
traffic  load,  a  DQDB  network  is  favored  for  its  low 
access  delays  to  asynchronous  traffic.  Morawer,  the 
FDDI  network,  which  is  based  on  token  ring  topology. 
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is  best  suited  for  local  area  networks,  while  the  DQDB 
network,  which  has  bus  topology,  has  been  adopted  by 
the  IEEE  802.6  Working  Group  as  a  standard  for 
metropolitan  area  networks.  On  tihe  other  hand,  ATM 
networks  are  best  suited  for  high-speed  wide  area 
networks.  Because  different  high  speed  networks  pose 
different  limitations  on  the  range  of  coverage,  and 
exhibit  different  characteristics  (e.g.,  access  delay, 
bandwidth  allocation),  in  the  foreseeable  future,  diverse 
multimedia  applications  will  reqinre  co-existence  of 
various  high  speed  networks  in  an  integrated  multi- 
media  network. 

To  achieve  interoperability,  many  researchers  have 
started  to  study  aspects  of  heterogaieous  higji  speed 
networks  interconnections  [9,10,11,12,13,14,15].  How¬ 
ever,  all  the  proposed  solutions  to  date  are  ad-hoc 
approaches  which  cannot  be  applkd  to  high  speed 
network  systems  other  than  their  raiginal  targets. 
Consequently,  they  are  expensive  ravl  limited.  In  this 
paper,  the  previously  proposed  formal  Synchronizing 
Transition  Set  (STS)  aIgorithm[2]  is  modified  in  an 
attempt  to  solve  the  protocol  conversion  problem  cost- 
effectively  in  multimedia  networks. 

Nevertheless,  protocol  conversion  in  multimedia 
networks  will  face  more  challengir^  issues  than  in 
traditional  data  networks.  For  example,  it  has  been 
projected  that  a  single  multimedia  network  could  be 
used  to  connect  every  HDTV,  video /audio  phone,  and 
work-station  in  a  wide  area.  Upon  successful  develop¬ 
ment  of  a  multimedia  network,  each  housdroki  of  the 
covered  area  will  be  able  to  simply  plug  their  HDTV 
sets  into  the  network  to  receive  TV  signals.  Similarly, 
after  plugging  in  a  video  phone,  video  phone  owners 
will  be  able  to  reach  others  just  by  cBaling  the  destina¬ 
tion  numbers.  In  this  scenario,  the  mimber  of  nodes 
connected  in  the  multimedia  networks  is  at  least  the 
number  of  households  in  the  covered  area.  As  a  result, 
the  connectivity  (number  of  nodes)  of  a  multimedia 
network  must  be  much  higher  than  a  traditional  data 
network.  Therefore,  in  addition  to  high  speed,  high 
connectivity  becomes  another  dondnant  characteristic  of 
a  multimedia  network  that  must  be  considered  in 
protocol  conversion.  Consequently,  the  traditional 
protocol  conversion  model  (Fig.  1)  is  no  longa-  feasible, 
as  shown  in  the  simulation  study  presented  in  Section  2. 
Thus,  in  contrast  to  the  traditional  conversion  model,  a 
model  that  performs  conversion  at  end  nodes  is  pro¬ 
posed  in  this  paper.  This  category  (rf conversion  is 
known  as  the  protocol  compensation  approach. 

In  the  remainder  of  tiiis  paper:  Section  2  presents  the 
simulation  results  that  demonstrate  frie  inappropriate¬ 
ness  of  the  traditional  conversion  model  in  multimedia 
networks;  Section  3  describes  the  protocol  compensation 
model;  in  Section  4,  an  example  from  [2]  is  used  to 
demonstrate  the  modified  STS  algorithm  step  by  step; 


Figure  1.  Traditional  conversion  mtxlel 


Section  5  presents  a  refinement  of  the  algorithm  for 
reducing  the  complexity  of  converter  composition  at 
step  4;  and  in  Section  6,  conclusions  are  presented. 


2.  Simulation 

In  this  section,  simulation  results  are  presented  to 
demonstrate  that  the  message  delays  introduced  by  a 
traditional  intermediate  node  converter  will  make 
multimedia  network  gateway  a  traffic  bottleneck.  The 
model  to  be  simulated  is  as  shown  in  Fig.  1,  in  which 
multiple  nodes  in  one  network  share  the  same  converter 
gateway  to  communicate  with  multiple  nodes  in 
another  network.  For  ease  of  simulation,  all  sessions  that 
cross  through  the  converter  are  assumed  to  have  the 
same  characteristics. 

In  general,  a  Monochrome- Video  has  a  window  size 
of  512  X  256  pixels.  Assuming  each  pixel  is  represented 
by  one  byte  of  data,  a  video  frame  would  thus  generate 
128K  bytes  of  data,  which  is  1  Mega-bits/per-frame. 

For  continuous  playback  of  a  video  program,  a  rate  of 
approximately  30  frames  per  second  is  necessary. 
Therefore,  to  support  one  continuous  video  playback 
multimedia  session,  approximately  30  Mbps  of  band¬ 
width  is  consumed.  However,  since  it  is  unlikely  that  a 
session  would  perform  such  costly  operation  all  the 
time,  the  actual  probability  p  that  a  session  has  a  vida) 
frame  ready  for  transmission  at  a  given  unit  of  time  (ms 
in  the  simulation)  varies  during  the  life  time  of  the 
session.  The  maximum  value  of  this  probability  p  is  0.03 
(=  30  frames  /  lOfXl  ms)  for  continuous  vida^  playback, 
and  it  has  lower  value  for  other  types  of  applications.  In 
the  simulations  presented,  different  values  of  p  are  used. 
Note  that,  for  the  ease  of  simulation,  when  a  value  of  p 
is  chosen  for  a  simulation  run,  its  value  remains  the 
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same  during  the  run;  also,  all  sessions  during  the  run 
will  have  the  same  value  of  p. 

Currently,  a  typical  high  speed  network  can  transmit 
data  in  the  range  of  a  few  hundred  Mbits /s  to  some 
Gbits/s.  To  match  the  high  speed,  very  high  throughput 
processors  must  be  used  at  converter  gateways.  Note 
that  even  with  the  highest  power  processors.  Axe 
maximum  converter  throughput  will  be  much  lower 
than  the  full  bandwidth  of  the  backbone  network  due  to 
the  latency  introduced  by  the  message  buffering  and 
conversion  processing  at  converter  gateways.  In  the 
presented  simulations,  converters  with  different 
throughputs  in  the  range  of  500  Mbits/s  to  15  Gbits /s 
are  considered,  and  for  the  simplicity  of  simulations,  the 
propagation  delay  is  ignored. 

In  short,  the  simulations  are  conducted  as  follows. 
Frames  ready  to  transmit  at  a  source  node  will  arrive  at 
a  converter  immediately.  A  converter  delivers  frames  in 
the  order  of  their  arrivals  (as  a  FIFO  queue).  In  a  unit  of 
time  (1  ms),  a  converter  can  deliver  at  most  an  amount 
of  data  (or  a  number  of  video  frames)  equal  to  its 
maximum  throughput;  i.e.  depending  upon  the  maxi¬ 
mum  throughput  of  the  converter  and  the  number  of 
frames  arrived,  a  converter  may  deliver  only  part  of 
them  in  a  unit  of  time.  If  the  remaining  throughput  at  a 
given  unit  of  time  is  not  enough  to  transmit  a  complete 
frame,  a  partial  frame  can  be  delivered;  the  rest  of  the 
partially  delivered  frame  will  have  higher  priority  for 
delivery  in  the  next  unit  of  time.  Therefore,  due  to  the 
limited  throughput  of  a  converter,  foose  frames  that 
cannot  be  delivered  inunediately  are  put  into  foe 
converter^ s  buffers.  Again,  for  the  sake  of  simplicity,  it  is 
assumed  that  all  converters  have  unlimited  buffers  such 
that  frames  are  never  discarded  at  a  converter.  In  such 
model,  the  transmission  delay  of  a  frame  is  the  period 
between  the  time  it  arrives  at  a  converter  and  the  time  it 
leaves  for  its  destination  (note  that,  fois  is  true  only 
because  of  the  assumption  of  no  propagation  delays  in 
the  simulations).  During  a  simulation  run,  the  transmis¬ 
sion  delay  encountered  by  a  frame  is  accumulated  into  a 
total  frame  delay  (in  ms).  This  accumulated  delay  is 
used  to  calculate  the  average  frame  dday,  which  is 
obtained  by  dividing  the  accumulated  delays  by  the 
total  number  of  frames  transmitted. 

Fig.  2,  in  which  the  converter  maximum  throughput  is 
500  Mbits/s,  shows  the  relationship  between  foe 
average  frame  delay  and  the  number  of  active  multime¬ 
dia  sessions  under  different  values  of  frame  generation 
probability  p.  The  same  simulation  is  also  run  against 
converters  with  maximum  throughputs  of  1  Gbits /s 
and  15  Gbits/s,  and  the  result  is  shown  in  Fig.  3  and  4, 
respectively.  The  actual  numbers  obtained  from  these 
simulations  are  listed  in  Table  1,2  and  3,  respectively. 
Note  that,  under  the  assumptions  of  these  simulations, 
using  1  converter  gateway  of  1.5  Gbits/s  throughput  is 


Figure  2.  Simulation  with  Converter  of  5(X)  Mbits/s 
Maximum  Throughput 


Figure  3.  Simulation  with  converter  1  Gbits/s  Maximum 
Throughput 


equivalent  to  using  simultaneously  3  converter  gate¬ 
ways  of  500  Mbits/s  throughput  each. 

From  the  results  of  these  simulations,  it  can  be  verified 
that  the  average  frame  delays  are  affected  the  most  by 
the  number  of  active  multimedia  sessions  and  the 
values  of  the  frame  generation  probability  p.  The 
average  frame  delays  grow  almost  exponentially  as  foe 
number  of  sessions  increases,  and  foe  probability  p 
affects  foe  growth  rates  of  foe  average  frame  delays:  foe 
higher  value  foe  probability  p  is,  foe  faster  foe  average 
frame  delays  grow.  In  fact,  as  the  number  of  sessions 
increases  steadily,  foe  converters  quickly  reach  foeir 
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The  bottleneck  effect  is  more  tolerable  in  traditional 
data  networks,  since  the  number  of  their  internal  nodes 
is,  in  general,  less  than  a  few  hundred  and  internetwork 
communication  is  relatively  less  frequent  In  fact,  the 
throughput  requirement  of  traditional  internetwork 
communication  is  in  the  range  of  hundreds  of  Kbits /s  or 
less;  therefore,  in  terms  of  network  interconnection,  a 
high  speed  bridge  would  suffice.  In  the  case  of  multime¬ 
dia  networks,  however,  high  connectivity  means 
increased  probability  of  traffic  through  the  converter/ 
gateway.  Coupled  with  the  high  bandwidth  require¬ 
ments  of  each  media  stream,  the  transmission  delay  at  a 
single  point  of  traffic  congestion  becomes  unmanage¬ 
able,  as  illustrated  by  the  simulations.  Clearly,  the 
traditional  intermediate  node  conversion  model  should 
be  avoided  in  a  high  connectivity  multimedia  network, 
and  a  more  efficient  approach  is  needed. 

3.  New  Model 


maximum  throughputs  and  the  frame  delays  become 
unmanageable.  Note  that  for  a  typical  multimedia  appli 
cation  of  continuous  video  playback  of  30  frames/s,  the 
maximum  acceptable  frame  delay  is  33  ms.  In  the 
traditional  intermediate  converter  model,  to  keep  the 
average  frame  delay  under  33  ms,  a  high  performance 
converter  of  1  Gbits/s  throughput  can  effectively 
support  less  tihan  100  sessions  only.  Even  though 
increasing  the  power  or  the  number  of  the  converters 
can  reduce  the  bottleneck  effect,  it  can  never  keep  up 
with  the  increase  in  number  of  sessions  in  an  integrated 
multimedia  network  with  high  connectivity.  Stil  these 
gateways  would  be  points  of  traffic  congestion  and 
delay  (as  shown  by  Table  2,  and  3). 


Table  1.  Simulation  with  500  Mbits/s  Throughput  Converter 


Figure  5.  Option  1  -  Conversion  at  receiving  node 
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To  avoid  bottleneck  effects,  tlie  new  i  lodel  eliminates 
the  intermediate  conversion  node  and  by  contrast, 
conversion  is  performed  at  either  of  the  end  nodes  as 
shown  in  Fig.  5  and  Fig.  6.  In  the  new  model,  it  is 
assumed  that  a  node  in  one  network  can  physically 
connect  to  another  network  by  simply  tapping  itself  into 
an  access  point  of  the  target  network,  in  the  same 
manner  that  plugging  in  a  telephone  establishes  a 
connection. 

In  Fig.  5,  node  N2  in  network  2  taps  itself  into  net¬ 
work  1  to  initiate  internetwork  communication  with 
ncxle  N1  in  network  1.  The  dotted  lines  between  node 
N2  and  network  1  denote  the  attachment  of  N2  to 
network  1.  From  node  NTs  viewpoint,  node  N2  is  only 
a  newly  added  node  in  netw  ork  1  running  the  same 
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Table  2.  Simulation  with  Gbit/s  Throughput  Converter 
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Table  3.  Simulation  with  1,5  Gbits/ s  Throughput  Converter 


protocol.  N1  and  N2  can  be  considered  as  two  nodes 
connected  by  the  same  high  speed  links  of  network  1. 
Therefore,  N1  would  use  the  regular  protocol  of  net¬ 
work  1  to  communicate  with  N2  witiiout  knowing  that 
N2  is  a  node  in  network  2.  To  keep  the  conversion 
transparent  to  high  level  application  programs,  node  N2 
performs  the  conversion  within  its  low  level  protocol 
entities.  In  the  dashed  box  of  Fig.  5.  protcxol  P  (of 
network  1)  is  used  between  nodes  N1  and  N2.  The 
transparency  property  requirement  defined  in[2]  is 
relaxed  in  the  sense  that  rfie  conversion  is  not  transpar¬ 
ent  to  the  low  level  protocol  entities  of  the  receiving 
node.  Still,  the  conversion  is  transparent  to  node  N1  and 
the  high  level  application  programs  of  node  N2.  Simi¬ 
larly,  when  N1  in  network  1  is  the  node  which  initiates 
the  internetwork  communication,  it  can  also  attach  itself 
to  network  2  as  shown  in  Fig.  6. 

In  this  protocol  compensation  model,  mxles  initiating 
internetwork  communication  perform  the  protocol 
conversion.  Therefore,  the  conversion  function  is 
decentralized  and  bottlenecks  are  eliminated.  Conse¬ 
quently,  high  speed  internetwork  communication 
becomes  more  plausible.  Moreover,  removing  the 
possible  single  point  of  failure  that  leads  to  nodal 
isolation  makes  this  model  more  fault  tolerant. 

Despite  the  aforementioned  advantages,  a  converter 
gateway  still  must  be  used  when  the  networks  to  be 
integrated  are  gec^graphically  separated  far  apart,  and 
tapping  into  other  networks  is  not  feasible.  However,  it 
should  also  be  noted  that  the  networks  in  a  multimedia 
network  environment  are  often  overlapped,  much  like 
telephone  networks  and  cable  TV  networks:  an  average 
household  often  contains  both  cable  TV  and  telephone 
outlets.  Two  networks  are  considered  to  be  overlapping 
if  they  cover  approximately  the  same  geographical  area, 
and  an  access  point  of  one  network  is  always  close  to  an 


Figure  6.  Option  2  -  Conversion  at  Sending  Ncxie 
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Figure  7.  Abstract  model  of  Cation  1. 


access  point  of  the  other.  In  this  sense,  if  a  node  needs  an 
extraordinarily  long  distance  link  (e.g.,  from  the  East 
Coast  to  the  West  Coast  of  the  United  States)  for  tapping 
into  the  other  network,  the  tapping  is  considered 
unreasonable  and  traditional  gateways  must  be  used. 

The  remainder  of  this  paper  focuses  on  deriving 
converters  in  option  1,  and  converters  in  option  2  can  be 
derived  similarly.  In  the  service  abstraction  of  option  1 
shown  in  Fig,  7,  the  conversion  is  performed  by  the 
converter  entity  C,  which  supports  the  service  interface 
of  protocol  Q,  while  at  the  same  time  using  protocol  P  to 
communicate  with  its  peer  entity  P^.  Note  that  prcHocol 
entities  and  Q,,  are  all  combined  into  a  single 
entity  C.  Since  protocol  Q's  peer  interface  (communica¬ 
tion  links  between  and  no  longer  exists  in  the 
new  model,  the  peer  transitions  of  protocol  Q,  which 
were  used  to  support  its  peer  interface,  need  not  be  used 
in  the  derivation  of  C.  Therefore,  the  abstraction  in  part 
(b)  of  Fig.  7  becomes  the  actual  model  used  in  the  paper. 
Consequently,  it  is  the  service  specification  diat 
participates  in  the  composition  of  converter  C  at  step  4 
of  the  modified  algorithm. 

4.  The  Algorithm 

For  ease  of  presentation,  the  second  example  from[2] 
is  used  to  give  a  step  by  step  demonstration  of  the 
modified  STS  algorithm.  Fig.  8  shows  the  given  proto¬ 
col  specifications  of  P  and  Q,  in  which  the  service 
transitions  are  labeled  in  capital  letters.  Protcxiol  P  is  a 
simple  non-sequence  protocol.  Protocol  Q  is  a  simplified 
flow  control  protcxrol.  Before  sending  each  data  packet 


from  to  Qy  a  reservation  needs  to  be  confirmed.  If 
has  no  space  available  to  receive  data,  it  can  send  a 
choke  message  to  to  stop  the  transmission.  The 
service  specifications,  Q^,  and  the  conversion  require¬ 
ment  R  are  as  shown  in  Fig.  9. 

In  the  STS  approach,  the  first  3  steps  of  the  algoritlim 
are  used  to  derive  the  inter-relationship  of  the  service 
transitions  at  the  protocol  boundary,  between  the 
service  transitions  of  P^,  and  In  the  new  model,  the 
conversion  is  performed  via  the  coordination  of  service 
transitions  also  at  the  boundary  between  P^^  and 
protocol  Q  (specifically,  also  between  P^,and  Q^.) 
Therefore,  tlie  first  3  steps  remain  the  same.  Tlie  result  of 
applying  0  (defined  in  [2])  to  ,  R  and  to  obtain 
the  service  system  graph  G  is  shown  in  Fig.  10. 

The  initial  projection  of  G  onto  the  service  transitions 
of  P^  and  is  shown  in  Fig.  11,  in  which  states  [1, 1, 2] 
and  [2, 3, 3]  can  be  removed  along  with  the  incidental 
null  transitions  as  described  in  [2].  The  result  is  shown 
in  Fig.  12,  in  wliich  state  [2, 2, 1]  (also  [1, 2,7]  has  incom¬ 
ing  null  and  non-null  transitions.  Tllis  situation  does  not 
meet  the  simple  conditions  described  in[2]  for  the 
aforementioned  state  removal.  In  this  case,  these  states 
must  not  be  excluded  from  the  FSM;  only  the  incidental 
null  transitions  can  be  removed.  To  do  so,  die  null 
transition  removal  procedure  from[2]  is  revised  as 
follows. 
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Revised  Null  Transirion  Removal  Prorp^^ii^-o 

1. For  each  NULL  transition  a,  if  a  is  the  only  outgoing 
transition  of  a  state  $t,  st  can  be  removed  along  with 
a  by  redirecting  the  incoming  transitions  of  st  to  the 
tail  state  of  a  [2]. 

2.  For  each  remaining  NULL  transition  a,  if  a  is  the  only 
incoming  transition  of  a  state  st,  st  can  be  removed 
along  with  a  by  changing  the  head  states  of  all  of  st 's 
outgoing  transitions  to  the  head  state  of  a  [2]. 

3.  For  each  non-NULL  transition  T,  whose  head  and 
tail  states  are  s  and  e,  respectively,  where  e  is  the  head 
state  of  a  NULL  transition  a,  add  a  new  transition  T 
from  state  s  to  the  tail  state  of  a. 

4.  For  each  non-NULL  transition  T  whose  head  and  tail 
states  are  s  and  e,  respectively,  where  s  is  the  tail  state 
of  a  NULL  transition  a ,  add  a  new  transition  T  from 
the  head  state  of  a  to  state  e, 

5.  Remove  all  the  remaining  null  transitions.  The 
resulting  FSM  is  equivalent  to  the  original  one. 


O-U _ 


Figure  10.  Example  -  Service  System  Graph  G 


After  applying  the  above  procedure,  the  conversion 
service  specification  obtained  is  shown  in  Fig.  13.  Next 
in  step  3,  a  synchronizing  transition  set  is  obtained  as 
follows: 

virtual  atomic  transition  VI  with 
synchronizing  transition  set  Sj 
DEL,RSV,CONF,IN  ) 


The  next  step  (step  4)  of  the  algorithm  is  toe  major 
difference  of  toe  new  model:  toe  converter  entity  C  in 
part  (b)  of  Fig7  is  composed  of  peer  protocol  entity  Pf, 
and  toe  entire  protocol  Q  (as  a  single  entity).  In  fact, 
protocol  Q  is  treated  as  an  entity  consisting  only  of 
service  transitions;  i.e.  the  participants  of  this  step  in  the 
new  model  are  and  Qj  instead  of  P^  -and  Q„  •  The 
same  coordinated  composition  operator  O  defin^  in[2] 
is  used  to  derive  protocol  entity  C: 

converter  entity  C  =  PjOQj 

The  result  of  applying  the  coordinated  composition 
operator  to  Pj  and  is  shown  in  Fig.l4.  One  may 
argue  that  contains  service  transitions  from 
which  are  not  needed  in  the  final  converter  specification 
and  should  not  participate  in  the  composition  either.  In 
answer  to  this  argument,  the  service  transitions  from 
are  needed  for  coordinating  purposes  in  the  coordinated 
composition  operation.  The  service  transitions  of  are 
synchronized  with  toe  peer  transitions  of  P^  by  toe 
coordination  of  toe  service  transitions  from  toe  synchro¬ 
nizing  transition  set  which  includes  service  transitions 
from  P^  and  .  In  short,  toe  service  transitions  from 
are  needed  to  serve  as  the  coordinating  media  in  this 


Figure  11.  Example  -  Initial  Projection 


In  the  example,  note  that  toe  synchronizing  transition 
set  contains  more  than  one  transition  from  that  have 
to  be  executed  in  a  single  virtual  atomic  transition[2]; 
i.e.,  RSV,  CONF,  and  IN  from  have  to  be  executed 
together  with  E®L  from  P^.  To  reduce  toe  complexity 
of  toe  coordinated  composition,  Q^,  can  be  simplified 
by  combining  toe  transition  sequence 
RSV.REQ.OK.CONF.IN 

(which  includes  toe  service  transitions  from  Sj )  into  a 
single  atomic  transition  before  toe  composition  with  P,, . 
In  Fig.  14,  Q'j  is  toe  simplified  service  specification  of 
protocol  Q,  which  in  turn  participates  with  P,,  in  the 
composition  operation. 
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Figure  12.  Example  -  Intermediate  Projection  Result 


Figure  13.  Example  -  Conversion  Service  Specification 


Note  that  the  converter  C  in  Fig.  17  has  no  service 
transitions  from  ;  therefore,  there  is  no  need  to 
perform  the  NULL  transition  removal  after  the  composi¬ 
tion.  Again,  the  final  converter  is  shown  in  Fig.  18  in 
which  the  redundant  states  [3,7]  and  [1,7]  from  Fig. 

16  are  excluded  as  expected.  Formally,  step  4  of  the 
revised  algorithm  is  as  follows: 

Step  4 

Let  the  set  of  service  transitions  of  Qa  be  Eq, 
and  the  synchronizing  transition  sets  be  Si,  where 
i  =  1  to  n,  and  n  is  the  number  of  synchronizing 
transition  sets  obtained  in  Step  3.  Define  sets  ©5. 
for  i  =  1  to  n  as  follows: 

05.  =  I  0  is  a  subsequence  of  a  legal  path  of 
^  Isq,  =  ‘S’i  Ieq,  >  ^  starts  and  ends  with 

transitions  from  5,} 

In  the  above  definition,  6  and  5,-  |sg,  de¬ 
note  the  projections  of  0  and  Si  onto  Eq,  ,  re¬ 
spectively.  In  the  example,  for  Si  =  {  DEL, 
RSV,  CONF,  IN  },  the  corresponding  65,  = 

{RSV.REQ.OK.CONF.IN}.  In  the  following  pro- 
cedures,  let  6^  '  denote  a  member  of  ©s, ,  where 
j  =  1  to  I  05.  |: 


Finally,  as  the  last  step  (step  5),  the  virtual  atomic 
transition  V  is  expanded  and  the  service  transitions  from 
(RSV  and  BUSY)  are  removed.  The  results  are  shown 
in  Fig.  15  and  16,  respectively. 

5.  Refinement 

It  can  be  verified  that  states  [3,  7]  and  [1, 7]  in  Fig.  16 
are  redundant  states.  This  indicates  the  need  for  further 
refinement  of  the  proposed  algorithm.  Note  that  these 
two  states  are  included  in  the  converter  entity  specifica¬ 
tion  at  step  4  when  the  coordinated  composition  operator 
0  is  applied  to  and  ,  which  contain  service 
transitions  (RSV  and  BUSY)  from  .  These  service 
transitions  are  eventually  removed  at  step  5.  In  fact,  when 
was  simplified  into  Q/ ,  the  coordinating  capability 
from  RSV  and  BUSY  has  been  instated  into  the  created 
atomic  transition  V' .  As  a  result,  RSV  and  BUSY  are  no 
longer  needed  as  coordinating  media.  Therefore,  they  can 
be  removed  before  the  composition  to  reduce  the  com¬ 
plexity  further.  InFig.  17,  all  Q/s  service  transitions  are 
removed  when  is  further  simplified  into  Q/'.Then, 
a  less  complex  converter  is  obtained  (by  applying  toe  O 
operation  to  and  Q/')- 


•  ©s 

1.  Create  an  atomic  transition  Vj  '  for  each 

In  Q,,  replace  each  with  the  cor- 
respor  i:ng  *  to  simpliP/  Q,,  The  exe- 

©s 

cution  of  Vj  *  represents  the  execution  of 

all  transitions  of  6j  in  an  atomic  manner. 
Denote  the  resulting  FSM  as  Q'.  In  the  ex¬ 
ample,  and  Q'  are  V'  and  Q',  respec¬ 

tively,  as  shown  in  Fig.  14  and  Fig.  17. 

2.  Use  the  null  transition  removal  algorithm  to 
remove  all  remaining  service  transitions  be¬ 
longing  to  Qa  from  Q'.  Denote  the  resulting 
FSM  as  Q'J. 

3.  Apply  the  coordinated  composition  opera¬ 
tion  O  to  Pb  and  Q'J  to  derive  the  converter 
entity  C. 
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Figure  14.  Example  -  Converter  Entity  C 


Figure  17.  Example  -  Refinement  of  Converter. 


Figure  15,  Example  -  Converter  Entity  C  (V  Expanded) 


Figure  18.  Example  -  Refined  Converter  with  V  Expanded. 


Figure  16.  Example  -  Converter  Entity  C  with  NULL 
Transitions  Removed. 


6,  Conclusion 

In  this  paper,  a  simulation  study  is  presented  to  show 
the  shortcomings  of  the  traditional  prpttKol  conversion 
model  in  multimedia  networks.At  the  conclusion  of  the 
simulation  study,it  is  shown  that  a  more  efficient 
conversion  model  is  needed.Thus,  to  achieve  better 
efficiency,  a  protocol  compensation  model  is  proposed  to 
perform  protocol  conversion  in  multimedia  networks. 
Under  this  protocol  compensation  model,  the  previously 
proposed  Synchronizing  Transition  Set  (STS)  algorithm 
is  modified  to  derive  converter  entity  at  end  nodes  in  an 
overlapping  multimedia  network  environment. 

Since  the  same  ®,  O  and  I  operations  are  used  as 
before,  a  formal  proof  of  correctness  for  the  modified 
algorithm  can  be  constructed  in  the  same  manner  as 
described  in  [2].  Moreover,  all  the  beneficial  characteris¬ 
tics  of  the  original  STS  approach  are  inherited  in  the 


I 
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modified  algorithm,  with  the  exception  of  the  transpar¬ 
ency  property  at  a  lower  layer  of  the  target 
protocol.These  characteristics  Lnclude,  but  are  not 
limited  to  less  complexity  by  using  the  service  specifica¬ 
tion  approach;  capability  of  converting  a  sequence  of 
transitions  as  a  unit;  liveness /conformity  properties; 
and  correctness  without  the  need  for  final  validation 
phase.As  emerging  hi^  speed  networks  continue  to 
mature,  it  is  believed  that  protocol  conversion  will  play 
an  important  role  in  developing  a  successful  integrated 
multimedia  network. 
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Abstract 

In  this  paper  we  address  the  issues  related  to  the 
delivery  of  multimedia  streams  on  local  area  net* 
works.  Multimedia  integrates  voice  and  video  along 
with  text  and  images  mto  existing  systems.  TVadi* 
tionally,  local  area  networks  were  designed  to  handle 
regular  data  traffic  which  are  bursty  in  nature  and  for 
which  variable  delay  is  acceptable.  Multimedia  traf> 
fic,  on  the  other  hand,  requires  constant  delay  in  ad¬ 
dition  to  fast  (or  real  time)  delivery.  Multimedia  tral^ 
lie  also  requires  large  bandwidth  compared  to  regular 
traffic.  Since  local  area  networks  are  widely  in  use, 
their  modification  to  integrate  multimedia  streams  is 
very  important.  In  this  paper  we  propose  priority- 
based  communication  schemes  for  the  timely  deliv¬ 
ery  of  multimedia  traffic  on  local  area  networks.  We 
compare  the  performance  of  these  schemes  using  sim¬ 
ulation  techniques. 

Key  words:  Multimedia,  local  area  networks,  pri¬ 
ority. 

1  Introduction 

Multimedia  is  a  media  that  integrates  the  transmis¬ 
sion  of  voice  and  video  along  with  text  and  images 
into  existing  systems  (1,2,3,4,51.  Digital  multime¬ 
dia  transmits  multimeffia  information  digitally  and 
allows  them  to  be  manipulated  and  stored  on  a  com¬ 
puter  system.  It  also  allows  for  interactive  human 
interface.  Interactive  multimedia  allows  the  user  to 
interface  with  the  system  in  real  time  which  is  im¬ 
portant  for  education,  business,  entertainment,  and 
communications. 
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A  large  number  of  commercial  organizations  as  well 
as  universities  use  some  type  of  local  area  network 
environment.  These  organizations  have  two  options 
for  adffing  multimedia  capabilities.  One  option  is 
to  utilise  the  existing  networks  by  adding  some  de¬ 
vices  and/or  software  in  order  to  transmit  multime¬ 
dia  streams.  The  other  option  is  to  use  an  ATM  type 
netwoA  (see  section  3.2).  ATM  is  designed  such  that 
vmee  aad  video  can  be  transmitted  effectively  along 
with  data  packets.  ATM  switches  and  interfaces  will 
be  needed  which  would  add  a  lot  of  cost  to  these  or¬ 
ganizations. 

Firisthig  local  area  networks  have  two  main  prob¬ 
lems  wfth  regard  to  the  integration  of  multimedia 
streams.  First,  the  existing  bandwidth  capability  for 
a  standard  LAN  does  not  support  multimedia  trans¬ 
mission  requirements.  Second,  there  is  no  explicit 
priority  mechanism  for  transmitting  data/stream  on 
LANs.  Multimedia  streams  must  be  received  at  the 
user/presentation  site  at  a  time  that  there  would  be 
no  intemption  (or  gap)  ftom  user’s  point  of  view 
(consider  a  moving  picture  presentation).  Note  that 
multimeffia  streams  are  isochronous  and  require  a 
constant  delay  between  packets. 

This  paper  focuses  on  the  problems  associated 
with  supporting  multimedia  on  local  network  envi¬ 
ronments.  The  protocols  of  the  local  area  networks 
are  not  suitable  for  multimedia  traffic.  They  were  de¬ 
signed  to  handle  regular  data  traffic  which  are  bursty 
in  nature  and  for  which  variable  delay  is  acceptable. 
Ikaditional  communication  protocols  for  local  area 
networks  have  to  be  modified  to  suit  the  needs  of 
multimeffia  applications.  We  present  protocols  for 
priority-based  communications  on  Ethernets  to  allow 
timely  defivery  of  multimedia  traffic  on  Ethernets  and 
compare  the  performance  of  the  possible  alternatives. 
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The  rcat  of  the  p»P<f  “  organized  u  follows:  In 
the  next  section,  we  pr«ent  daU  requirements  of 
multimedia  systems.  In  Section  3,  we  give  a  brief 
background  of  communication  networks.  Section  4 
presenU  two  techniques  for  priority-based  communi¬ 
cation  on  Ethernets.  In  Section  5,  we  proent  a  sim¬ 
ulation  study  of  the  proposed  techniques.  Finely, 
Section  6  concludes  the  paper. 

2  Multimedia  Data  Require¬ 
ments 

All  digital  media  requires  digital  end-to-end  trans¬ 
mission  of  multimedia  data  streams.  This  means  that 
the  communication  network  must  support  the  trans¬ 
mission  of  digitized  voice,  video  and  images.  The 
network  must  also  have  a  wide  bandwidth  to  sup¬ 
port  these  transmissions.  Not  all  existing  networks 
have  sufficient  bandwidth  to  accommodate  the  needs 
of  all  kinds  of  multimedia  applications.  For  example, 
a  LAN  with  10  Mbps  bandwidth  may  be  able  to  pro¬ 
vide  limited  support  to  tranter  video  and  imag«  for 
some  multimedia  applications. 

Multimedia  applications  require  fast  processing 
and  small  visual  response  time.  Moreover  the  effect 
of  latency  in  transmitting  streams  between  stations 
should  be  minimized  or  eliminated. 

Moreover  the  amount  of  storage  required  by  mul¬ 
timedia  data  is  much  more  than  that  of  regular  data. 
A  640  X  480  24-bit  color  resoluticm  graphic  image,  for 
example,  takes  about  900KB  memory.  Most  com¬ 
mon  audio  CD  uses  16-bit  resolution  and  44.1KHs 
sampling  rate.  One  second  at  this  high  quality  audio 
requires  176.4  kB  of  storage.  Vedio  is  composed  of 
a  stream  of  frames  (e.g.,  NTSC  uses  30  per  second). 
One  second  of  30  fjps  video  size  640  x  480  pixels 
and  24  bit  color  resolution  requires  about  27MBp8 
bandwidth. 

Multimedia  data  compr^on  techniques  reduces 
the  amount  of  bandwidth  required  by  streams  such 
as  video.  In  addition,  the  amount  of  disk  storage  re¬ 
quired  for  multimedia  data  can  be  substantially  de¬ 
creased.  The  27MBps  transfer  rate  required  for  the 
640  X  480  screen  would  be  reduced  to  SSOkBps  using 
the  MPEGl  standard  [6].  MPEGl  can  also  compress 
audio  by  a  factor  of  6-10. 

It  is  clear  that  the  amount  of  data  needed  to  repre¬ 
sent  video  digitally  places  tremendous  requirements 


on  storage,  transmission,  bandwidth  as  well  as  dis¬ 
play  capabilities  of  current  systems.  In  addition  to 
the  storage  and  bandwidth  requirements  for  multi- 
media  data,  there  are  some  other  problems  associ¬ 
ated  with  multimedia  such  as  the  suitability  of  exist¬ 
ing  network  protocols.  More  information  about  the 
properties  of  the  multimedia  data  types/streams  and 
the  requirements  of  multimedia  applications  can  be 
found  in  [7,8]. 

3  Communication  Network 
Background 

3.1  Local  Area  Networks 

Local  urea  networks  (LAN)  exist  in  one  of  the  fol¬ 
lowing  architectures',  bus,  tree,  token  ring  and  FDDI 
(Fiber  Dual  Data  Interface)  ring  [9,10].  The  most 
widely  used  LAN  is  the  Ethernet  which  is  a  bus-based 
architecture.  This  type  of  network  typically  has  10 
Mbps  bandwidth  as  opposed  to  100  Mbps  for  FDDI. 

Local  area  network  bus  (non  token)  protocols 
are  based  on  broadcasting.  The  most  dominat¬ 
ing  medium  access  protocol  (MAC)  in  use  is  the 
CSMA/CD  (Carrier  Sense  Multiple  Access  with  Col¬ 
lision  Detection)  in  which  each  station  listens  to  the 
channd  while  transmitting.  In  case  a  collision  is  de¬ 
tected  during  transmission,  the  station  ceasa  trans¬ 
mission  and  retria  after  some  (random)  period  of 
time.  This  protocol  requires  that  the  menage  size 
be  longer  than  twice  the  propagation  time  (in  order 
to  detect  collision  before  transmission  is  complete). 
It  also  use  binary  exponential  backoff  technique,  in 
which,  after  each  repeated  collision,  the  mean  value 
of  the  random  delay  is  doubled. 

One  other  MAC  that  is  widely  used  is  the  token 
bus  in  which  stations  on  the  bus  form  a  logical  ring 
with  a  token  (control  packet)  to  regulate  access  to 
the  medium.  When  a  station  receives  the  token,  it 
get  control  of  the  medium  for  a  specified  time.  When 
the  station  is  done,  or  time  expires,  it  passes  the  token 
to  the  next  station  in  the  logical  ring. 

LAN  topologies  are  based  on  sharing  the  band¬ 
width  between  stations.  Data  sent  are  assumed  to  be 
time-independent,  they  can  be  broken  into  packets 
without  regard  to  their  order.  Also,  when  a  station 
is  using  the  network  for  transmission,  no  other  st». 
tion  can  and  the  entire  bandwidth  is  assigned  to  it. 
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Options  for  Multimedia: 

To  overcome  the  problems  with  the  speed  and/or 
order  of  transmission  on  LAN,  several  alternatives  are 
being  explored.  Fast  Ethernet  is  one  way  to  solve  the 
bandwidth  problem  of  the  standard  Ethernet  and  it 
is  expected  to  be  10  tiroes  wider.  It  may  retain  the 
CSMA/CD  MAC  protocol  to  allow  internetworking 
with  standard  Ethernet  LANs. 

Another  way  to  overcome  the  bandwidth  problem 
is  to  use  switching  hubs.  Switched  Ethernet  estab* 
lisbes  a  single  point-to-point  LAN  between  each  work¬ 
station  and  a  high-capacity  switching  bub  [11].  This 
gives  each  workstation  its  own  LAN  with  all  of  its 
bandwidth.  (Some  topologies  may  have  more  than 
one  workstation  per  LAN.)  However  the  switching 
bub  may  be  a  bottleneck  at  some  point.  That  is  why 
this  network  architecture  imposes  limits  on  the  num¬ 
ber  of  workstations  that  could  be  connected  to  the 
hub,  and  also  on  the  number  of  simultaneous  users. 

Other  options  include  using  FDD!  (running  over 
twisted  pair  for  a  short  distance)  to  increase  the  band¬ 
width  to  100  Mbps.  FDDl  te^nology  could  be  ex¬ 
tended  to  support  the  timely  delivery  required  by 
multimedia  applications.  Isochronous  Ethernet  is  an¬ 
other  option  which  provides  isochronous  channels  to 
stations  equipped  with  isoENET  cards  [12]. 


3.2  Switching  Networks 

Switching  networks  transfer  information  between 
source  and  destination  via  three  functions:  transmis¬ 
sion,  multiplexing,  and  switching.  Transmission  pro¬ 
vides  the  point-to-point  transfer  of  information.  Mul¬ 
tiplexing  uses  a  single  transmission  facility  (link)  for 
several  independent  channels.  Switching  uses  prop¬ 
erties  of  telecommunications  traffic  to  replace  a  fully 
meshed  network  interconnecting  all  pairs  of  users 
with  a  shared  substructure  providing  on  demand  con¬ 
nections,  that  is,  packets  can  be  assinged  to  channels 
based  on  the  address  information  in  the  header  of  the 
packets  themselves. 

Circuit  switching  networks  use  time  division  mul¬ 
tiplexing  (TDM)  where  bandwidth  is  multiplexed 
between  several  cbanneb  with  assigned  amounts  of 
bandwidth.  Time  slots  within  a  frame  are  allocated 
to  the  channel  for  the  duration  of  the  service.  This 
type  of  networks  is  suitable  for  applications  that  re¬ 
quire  guaranteed  bandwidth  or  low  latency  such  as 
PCM  voice  and  constant  bit  rate  data  traffic.  The 


mode  of  transfer  in  this  type  of  network  is  referred  to 
as  synchronous  transfer  mode  (STM). 

Packet  switching  networks  use  bandwidth  effi¬ 
ciently  to  suit  bursty  applications  such  as  file  trans¬ 
fers.  However,  the  delay  in  these  networks  is  unpre¬ 
dictable  and  the  latency  tends  to  be  high.  Packet 
switching  uses  statistical  multiplexing  which  dynam¬ 
ically  allocates  time  slots  to  incoming  channels  based 
on  demand.  In  contrast  with  synchronous  TDM,  the 
positional  significance  of  the  slots  (in  TDM)  is  lost 
and  hence  each  packet  has  to  carry  addressing  infor¬ 
mation  in  addition  to  data. 

ATM  (Asynchronous  Transfer  Mode)  uses  cell 
switching  which  uses  bandwidth  flexibly  and  effi¬ 
ciently  for  all  sorts  of  applications.  For  constant  rate 
applications,  a  guaranteed  number  of  cells  per  sec¬ 
ond  can  be  allocated  and  any  unused  cell  slots  can  be 
allocated  (on  demand)  to  bursty  applications.  In  ad¬ 
dition,  the  number  of  virtual  channels  carrying  these 
cells  can  vary  as  well  as  the  rate  of  each  channel. 

In  cell  switching  technology,  a  cell  is  a  53  byte 
fixed  length  packet  with  5  bytes  for  header  (contain¬ 
ing  routing  and  quality  of  service  information)  and 
48  bytes  for  data  (payload  section)  [13].  This  fixed 
length  cells  are  better  suited  for  high  speed  switching 
because  it  enables  simpler  implementation  of  switches 
and  provides  predictable  system  behavior. 

The  asynchronous  nature  of  ATM  comes  &om  the 
fact  that  cells  are  assigned  asynchronously  to  any  ser¬ 
vice  based  on  its  needs.  This  is  facilitated  by  the  fact 
that  eadi  cell  is  addressed  independently  to  any  des¬ 
tination.  In  this  mode  of  tr^tnsmission,  there  is  no 
notion  of  owning  a  time  slot  on  periodic  basis. 

Although  existing  wide  networks  (WAN)  can  be 
used  by  some  multimedia  applications,  these  WAN- 
based  applications  would  suiTer  from  existing  prob¬ 
lems  such  as  the  varying  network  delays.  When  it 
become  widely  available,  ATM  will  be  a  suitable  tech¬ 
nology  that  has  the  high  bandwidth  and  low  latency 
requirements  for  many  multimedia  applications. 


4  Priority  Schemes 

As  mentioned  before,  our  work  focuses  on  the  prob¬ 
lems  associated  with  supporting  multimedia  services 
on  local  network  environments.  The  protocols  for 
regular  data  transfer  on  the  local  area  networks  are 
not  suitable  for  multimedia  traffic  and  they  have  to 


374 


be  modified  to  suit  multimedia  applications.  These 
protocols  were  designed  to  handle  regular  data  traffic 
which  is  bursty  in  nature  and  for  which  variable  delay 
is  acceptable.  We  present  priority-based  communicar 
tion  protocols  for  allowing  timely  delivery  of  multi- 
media  traffic  on  local  area  networks.  We  focus  our 
attention  to  the  problems  associated  with  supporting 
multimedia  traflBc  on  with  local  area  bus  (Ethernet) 
as  opposed  to  token  ring  networks  [14]. 

The  current  medium  access  bus  protocol  does  not 
provide  priority  for  transfer  of  data.  Stations  on  the 
bus  use  the  CSMA/CD  protocol  to  compete  for  bus 
bandwidth.  This  means  packets  can  indiscriminately 
collide  and  get  retransmitted.  This  medium  acce^ 
protocol  is  suitable  for  regular  data  traffic  but  not  for 
multimedia  traffic.  We  propose  two  priority  schema 
that  add  some  sense  of  priority  to  data  traffic  on  the 
bus.  They  support  two  levels  of  priority:  high  priority 
(for  multimedia  or  real-time  traffic)  and  low  priority 
(for  regular  data). 


Tm  Tr  Tm  Tr 
Figure  1.  Bus  Time 


4.1  Bus-Time  Multiplexing  Priority 
Scheme 


Bus-time  multiplexing  scheme  relies  on  message  pass¬ 
ing  to  support  two  levels  of  priority.  Before  a  station 
sends  a  "high  priority"  traffic  (for  a  multimedia  ses¬ 
sion),  it  informs  every  other  station  of  its  intention 
so  that  they  would  abstain  from  sending  "low  prior¬ 
ity"  traffic  for  a  period  of  time.  This  is  accomplished 
by  broadcasting  a  requ^t  me^ge  that  includes  the 
amount  of  time  that  the  station  needs  (i.e.,  the  ses¬ 
sion  length).  During  this  time  period,  only  high  pri¬ 
ority  traffic  is  allowed  to  use  the  bus. 

Since  the  requ^t  m^age  will  compete  for  the  bus 
with  other  traffic,  the  scheme  has  to  ensure  that  this 
m^sage  gets  succe^fully  transmitted  before  the  high 
priority  traffic  period  starts. 


When  stations  receive  a  message  indicating  that 
high  priority  traffic  need  to  be  sent  by  a  station,  they 
stop  sending  low  priority  traffic  at  once.  Stations 
record  the  time  at  which  they  will  be  allowed  to  send 
regular  traffic.  This  time  would  be  equivalent  to  the 
current  time  plus  the  length  of  the  session  (which  is 
included  in  the  request  message).  Stations  also  keep  a 
count  of  the  number  of  multimedia  sessions  currently 
in  progre^.  Whenever  a  station  receives  a  request 
m^sage,  it  increment  this  count  by  one. 

Within  a  high  priority  period,  if  another  station 
wants  to  start  a  multimedia  session,  it  can  use  the 
bus  simultaneously  since  it  knows  that  the  bus  is  be¬ 
ing  used  for  high  priority  traffic.  However,  the  sta¬ 
tion  has  to  send  a  (request)  message  to  other  sta¬ 
tions.  This  message  will  be  used  to  update  the  time 
at  which  the  high  priority  period  will  terminate.  In 
addition,  stations  will  increment  the  niimber  of  cur¬ 
rent  multimedia  sessions  by  one.  During  this  time 
period,  high  priority  traffic  compete  for  the  bus  us¬ 
ing  the  CSMA/CD  medium  access  protocol  (but  they 
do  not  compete  with  low  priority  traffic). 

After  a  station  has  finished  sending  its  high  pri¬ 
ority  traffic,  it  broadcasts  a  completion  message  in¬ 
dicating  that  the  number  of  multimedia  sessions  is 
decremented  by  one.  Again  the  scheme  has  to  ensure 
that  the  completion  message  gets  delivered  even  after 
it  collide  with  other  traffic. 

Thus  the  bus  is  time  multiplexed  between  high  pri¬ 
ority  and  low  priority  traffic,  as  illustrated  by  Figure 
1,  where  Tm  is  time  period  used  by  multimedia  (high 
priority)  traffic  and  Tr  is  time  period  during  which 
regular  (low  priority)  traffic  can  be  sent. 

The  period  (Tm)  during  which  the  bus  time  is  dedi¬ 
cated  to  multimedia  traffic  is  measured  from  the  start 
of  the  high  priority  traffic  session(s).  This  period  ends 
when  the  count  of  multimedia  sessions  goes  down  to 
zero  or  if  Tm  exceeds  a  pre-determined  maximum 
limit.  If  Tm  exceeds  this  limit,  regular  traffic  will 
be  allowed  to  use  the  bus.  The  ratio  Tm/TV  need  to 
be  chosen  carefully  to  insure  fairness  to  regular  data 
traffic. 

The  number  of  simultaneous  multimedia  sessions 
has  to  be  limited,  otherwise,  they  would  interfear 
with  each  other  producing  low  quality  in  addition  to 
increasing  the  regular  data  traffic  delay.  This  limita¬ 
tion  is  dependent  on  the  amount  of  available  band¬ 
width  and  the  nature  of  the  multimedia  applications. 

This  technique  should  result  in  better  multimedia 
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traffic  performance  over  the  non-prioritized  bus  pixy 
tocol,  but  regular  data  traffic  wiU  suffer  some  delay. 
This  delay  could  be  acceptable  to  a  user  sending  regu¬ 
lar  data.  On  the  other  hand,  a  delay  in  video  frames, 
for  example,  may  result  in  an  unacceptable  presenta¬ 
tion  quality. 


4.2  Station  Multiplexing  Scheme 

In  the  station  multiplexing  scheme,  each  station  keeps 
status  information  about  the  transmission  requests 
of  all  other  stations.  Using  this  status  information, 
each  station  will  be  able  to  make  decision  to  send 
packets  on  the  bus.  E!ach  station  is  still  required  to 
send  a  request  message  before  starting  its  multime¬ 
dia  session  (i.e.,  high  traffic  session),  but  stations  are 
not  required  to  send  a  message  after  completing  their 
sessions. 

In  this  scheme,  each  station  maintains  a  data  struc¬ 
ture  that  has  an  entry  for  each  station.  The  entry  for 
a  station  contains  the  time  of  the  latest  transmission 
request  made  by  that  station  for  high  priority  traffic. 
An  entry  for  a  station  is  updated  when  a  (request) 
message  is  received  indicating  that  it  wants  to  start 
its  multimedia  session. 

All  stations  use  a  fixed  length  quantum  (Tq)  for 
high  priority  traffic.  A  station  uses  the  bus  for  this 
quantum  and  renews  its  request  for  another  after  the 
current  quantum  expires.  A  station  wanting  to  start 
a  session  or  renew  its  request  for  another  quantum, 
compares  the  timestamps  in  its  local  structure.  The 
station  that  corresponds  to  the  smallest  timestamp  is 
the  one  that  can  use  the  bus  next  (after  the  current 
quantum  expires). 

A  station  can  find  if  the  current  quantum  has  ex¬ 
pired  by  comparing  the  difference  between  the  latest 
(highest)  timestamps  in  its  local  structure  and  the 
current  time  with  the  default  session  length  quantum. 
If  the  current  time  minus  the  value  of  the  latest  times¬ 
tamp  is  less  than  or  equal  the  value  of  Tq,  the  station 
may  proceed  with  its  request  immediately.  Other¬ 
wise,  the  station  tries  whenever  the  current  quantum 
expires. 

In  this  scheme,  the  bus  time  is  still  multiplexed 
between  high  priority  and  low  priority  traffics,  but  in 
addition,  the  Tm  period  is  further  divided  into  small 
time  quanta  (of  duration  Tq)  and  each  station  uses 
a  quantum  (if  needed)  based  on  the  latest  timestamp 
criterion  stated  above.  This  would  improve  perfor¬ 


mance  further  since  the  competition  between  stations 
(durmg  Tm)  is  regulated.  In  other  words,  this  ap¬ 
proach  further  reduces  the  possibility  of  collisions. 

The  basic  idea  is  that  stations  that  need  to  send 
high  priority  traffic  will  use  the  bus  in  a  last  recently 
used  order.  The  station  with  the  oldest  (smallest) 
timestamp  will  be  allowed  to  use  the  bus  once  the 
current  Tq  expires. 

If  two  stations  send  their  request  messages  at  the 
same  time,  these  messages  will  collide.  In  such  cases, 
one  station  will  backoff  its  transmission  of  request 
message  and  the  other  will  proceed.  (Station  num¬ 
bers  can  be  used  for  tie  breaking.) 

As  in  the  previous  scheme,  the  period  (Tm)  during 
which  the  bus  is  dedicated  to  multimedia  traffic  has 
a  maximum  length  from  the  start  of  the  high  priority 
traffic  ses8ion(s).  If  Tm  exceeds  this  limit,  regular 
traffic  will  be  allowed  to  use  the  bus.  Again,  the  ratio 
Tm/lV  need  to  be  chosen  carefully  to  ensure  fairness 
to  regular  data  traffic. 

A  variation  of  this  scheme  is  round  robin  scheme, 
where  stations  are  served  in  a  pre-defined  order  and 
for  a  fixed  period  of  time.  This  scheme  is  similar  to 
a  token  based  scheme,  where  stations  pass  a  token 
among  themselves  in  a  pre-defined  order  and  only 
the  station  that  has  the  token  can  use  the  bus  for  its 
high  priority  traffic  for  a  predefined  period.  When 
timer  expires,  station  passes  the  token  to  the  next 
one.  While  this  scheme  reduces  the  competition  be¬ 
tween  sUtions  trying  to  send  high  priority  traffic,  it 
may  result  in  an  unacceptable  response  time  for  some 
demanding  users. 


5  Simulation  Results 

An  event-driven,  discrete  time  simulators  of  the  pro¬ 
posed  priority  schemes  was  written  to  study  their  per¬ 
formance  under  various  mixes  of  high  priority  and 
low  priority  traffics.  The  simulators  were  written  in 
CSIM. 

The  performance  measure  studied  was  the  mean 
response  time  or  average  end-to-end  delay.  It  is  the 
time  mterval  between  the  instant  a  packet  is  ready 
to  be  transmitted  and  the  instant  the  packet  is  deliv¬ 
ered. 

We  studied  the  performance  of  the  following  three 
schemes: 
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•  A  no  priority  scheme:  this  schema  does  not  give 
priority  to  multimedia  traffic. 

•  An  absolute  priority  scheme:  this  schemes  giva 
absolute  priority  to  multimedia  traffic.  Low  pri¬ 
ority  traffic  had  to  wait  whenever  there  is  high 
priority  traffic  to  be  sent. 

•  Bus-time  multiplexing  scheme:  this  schemes  di¬ 
vides  the  time  into  two  intervals.  One  during 
which  only  multimedia  traffic  can  be  sent  and 
another  where  both  traffic  types  can  be  sent. 
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The  first  scheme,  namely  the  non  priority  scheme 
was  studied  to  compare  its  performance  with  the 
other  priority  schemes.  This  scheme  basically  ung¬ 
ulates  an  Ethernet/bus  protocol.  It  is  expected  that 
the  average  end-to-end  delay  for  this  scheme  to  be 
high  and  not  suitable  for  multimedia  traffic. 

The  abolute  priority  works  as  follows.  Each  station 
gives  higher  priority  to  multimedia  traffic.  Any  low 
priority  packects  will  not  be  transmitted  as  long  as 
there  are  some  high  priority  traffic  need  to  be  trans¬ 
mitted.  Thu  scheme  gives  the  best  performance  av¬ 
erage  raponse  time  (a  lower  bound  on  delay)  for  high 
priority  traffic.  On  the  other  hand,  it  wiU  result  in 
the  worst  performance  for  low  priority  traffic. 

The  simulator  used  the  parameters  of  a  10  Base 
5  Ethernet  that  has  a  bandwidth  of  10  Mbps.  The 
maximum  propagation  delay  U  2.5  micro  seconds.  A 


packet  of  size  IK  bits  have  100  micro  seconds  trans¬ 
mission  time.  Unless  otherwise  stated,  the  proba¬ 
bility  that  the  next  request  for  the  bus  is  for  high 
priority  traffic  equaU  0.5. 

Figures  2  and  3  show  the  mean  response  time  (in 
ms)  for  the  three  schemes  as  the  number  of  work¬ 
stations  (multimedia  sessions)  increase.  In  Figtire  2, 
packet  size  U  IK  bits,  while  in  Figure  3  the  packet 
size  U  8K  bits. 

We  observe  that  the  absolute  priority  scheme  give 
the  best  results  for  high  priority  traffic.  It  improves 
the  response  time  of  high  priority  traffic  by  a  about 
60  percent.  However,  we  found  that  the  performance 
of  low  primity  traffic  performance  was  severely  de¬ 
graded.  It  degraded  the  performance  of  regular  traffic 
by  a  factor  35.  In  addition,  it  completely  shut  off 
regular  traffic  as  the  number  of  stations  (multimedia 
sosions)  increased  beyond  ten. 
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Bmt  3.  R»)onse  tine  vs.  number  of  station 
for  8K  bio  padcets 


The  bus-time  multiplexing  scheme  produced  better 
overall  results  for  both  low  priority  and  high  priority 
traffic  than  a  non-prioritized  scheme  or  an  absolute 
priority  scheme.  It  improved  the  response  time  for 
high  priwity  traffic  by  a  about  35  percent,  and  de¬ 
graded  the  performance  of  regular  traffic  by  only  a 
factor  ^  6. 

Figure  4  shows  the  probability  of  discarding  high 
priority  packects  due  to  their  arrival  after  their  dead- 
lina  for  the  three  schemes  under  study.  We  assumed 
that  packet  size  is  IK  bits  and  a  high  priority  packet 
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misses  its  deadline  (i.e.,  is  of  no  value  to  the  applicsr 
tion)  if  it  does  not  reach  its  destination  in  100  ms. 


<tX) 


We  observe  that  the  absolute  priority  scheme  re¬ 
duces  the  probability  of  discarding  high  priority 
packet  by  a  factor  of  5.  The  bus-time  multiplexing 
scheme  reduces  the  probability  of  discarding  high  pri¬ 
ority  packet  by  a  factor  of  3.  Note  that  tl^  is  quite 
an  improvement  over  the  no-priority  scheme  that  has 
a  relatively  high  deadline  miss  rate  which  adversely 
affects  the  quality  of  service. 
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Figure  5  shows  the  results  for  a  system  where  80 
percent  of  the  transmission  requests  are  for  high  pri. 
ority  traffic  and  20  percent  for  regular  traffic.  By 
comparing  Figure  2  and  Figure  5  we  observe  that  the 
performance  of  high  priority  traffic  suffers  when  the 
fraction  of  high  probability  traffic  is  higher.  This  is 
due  to  the  fact  that  there  is  more  contention  among 
high  priority  requests  on  the  bus. 

We  observe  that  the  absolute  priority  scheme  still 
give  the  best  performance  for  the  high  priority  traffic. 
However,  the  bus-time  multiplexing  scheme  gives  the 
best  overall  performance  for  both  types  of  traffics. 

6  Conclusions 

IVaditional  medium  access  protocols  for  Ethrenet  do 
not  support  the  concept  of  priority  for  data  traffic. 
Stations  along  the  bus  equally  compete  for  bus  band¬ 
width.  This  means  that  packets  can  indiscriminately 
collide  and  get  retransmitted.  This  medium  access 
protocol  is  suitable  for  regular  data  traffic  but  not 
for  multimedia  traffic.  The  problem  with  multimedia 
streams  is  that  they  are  isochronous  in  nature  and 
they  need  to  be  delivered  in  real  time.  Thus  a  mix¬ 
ture  of  (multimedia  and  regular)  traffic  on  a  LAN 
bus  would  not  satisfy  this  requirement.  Multimedia 
traffic  need  to  be  transmitted  at  higher  priority  than 
regular  data  traffic. 

This  paper  focused  on  supporting  timely  delivery 
of  multimedia  traffic  on  local  area  networks.  We 
introduced  two  schemes,  the  bus-time  multiplexing 
scheme  and  the  station  multiplexing  scheme,  for  pri¬ 
ority  transmission  of  data  on  an  Ethernet.  These 
schemes  add  a  sense  of  priority  to  the  traffic  on  the 
bus. 

The  bus-time  multiplexing  scheme  supports  two 
leveb  of  priority  (high  priority  and  low  priority)  and 
multiplexes  the  bus  time  between  the  two  traffic 
types.  It  relies  on  sending  a  message  to  inform  all 
stations  that  bus  should  be  used  for  high  priority  traf¬ 
fic  for  some  period  of  time  during  which  low  priority 
traffic  are  not  transmitted.  This  technique  results 
in  a  better  multimedia  traffic  performance  over  the 
no-priority  bus  protocol  but  regular  data  traffic  will 
suffer  some  delay.  This  delay  could  be  acceptable  to 
a  user  sending  regular  data.  On  the  other  hand,  a 
delay  in  video  frames,  for  example,  may  result  in  an 
unacceptable  presentation  quality. 

In  the  station  multiplexing  scheme,  the  bus  time  is 
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^Ttly  used  criteria.  This  improve.  performan«  fur- 
thet  Lee  the  competition  betwem  .tMiOM 
the  hi,h.priorit,.period  U  tejulwed  .hieh  in  rffeet 
reduce  the  number  of  collisions. 

The  two  schemes  presented  here  reserve  bus  time 
for  a  specified  time  duration,  while  the  scheme  pre¬ 
sented  in  [15]  provides  messafe-based  priority  func¬ 
tions.  At  the  end  of  each  transmission  each  sUtion 
evaluates  its  priority  compared  to  the  priority  of  the 
current  transmission.  In  our  schem«,  during  the  tune 
reserved  for  high  priority  traffic,  there  is  no  need  for 
request/reservation  meraagM  which  in  effect  reduces 
the  protocol  overhead. 

Simulation  results  indicate  that  the  bus-time  multi¬ 
plexing  scheme  gives  the  best  overall  performance  for 
both  types  of  traffics  compared  with  a  non-pnoritiied 
scheme  or  a  scheme  that  giv«  absolute  priority  to 
multimedia  traffic. 


REFERENCES 

1.  S.  Ramanathan  and  Venkat  Rangan,  "Feed- 
back  Techniques  for  Intra-Media  Continuity  and 
Inter-Media  Synchronization  in  Distributed  Mul¬ 
timedia  Systems,"  The  Computer  Journal,  Vol. 
36,  No.  1,  1993, 19-31. 

2  T.  D.  C.  Little  and  A  Ghafoor,  ”  Multimedia  Syn¬ 
chronization  Protocols  for  Broadband  Integrat^ 
Services,”  IEEE  Journal  on  Selected  Areas  in 
Communication,  1991, 1366-1482. 

3  R.  B.  Dannenberg,  "Remote  Access  to  Interac- 
tive  Media,"  SPIE,  Vol.  1785,  Enabling  Tech¬ 
nologies  for  High-Bandwidth  Applications,  1992, 
230-237. 

4.  R.  Steinmetz,  "Synchronization  Properties  in 
Multimedia  Systems,”  IEEE  Journal  on  Selected 
Areas  in  Communication,  1990, 401-412. 

5.  C.  Nicolaou,  "An  Architecture  for  Real-Time 
multimedia  Communication  System,"  IEEE 
Journal  on  Selected  Areas  in  Communication, 
Vol.  8,  No.  3,  April  1990,  391-400. 


6  Bernard  Cole,  "The  Technology  Framework,” 
IEEE  Spectrum,  Vol  30,  No.  3,  March  1993, 
32-39. 

7.  Amr  Elsaadany,  Mukesh  Singhal  and  Ming  T. 
Liu  "Multimedia  on  Local  Area  Networks, 
Technical  Report  OSU-CISRC-3/94-TR11,  CIS 
Dept.,  OSU,  March,  1994. 

8.  Jeff  Burger,  "The  Desktop  Multimedia  Bible," 
Addison  Wesley,  1993. 

9.  William  Stallings,  "Data  and  Computer  Com¬ 
munications,”  Macmillan  Publishing,  Second 
Edition,  1988. 

10.  Andrew  S.  Tanenbaum,  "Computer  Networks, 
Printce  Hall,  Second  Edition,  1989 

11.  Fouad  A.  Tobagi,  "Multimedia:  The  Challenge 
Behind  the  Vision,"  Data  Communications,  Jan 
21,  1993. 

12.  Daniel  Minoli,  "Isochronous  Ethernet:  Poised 
for  Launch,"  Network  Computing,  August  1993, 
156-162. 

13.  William  Stallings,  "ISDN  and  Broadband 
ISDN,”  Macmillan  Publishing,  Second  Edition, 
1992. 

14.  Khaled  Amer,  Ken  Christensen  and  Tom  Toher, 
-Experiments  with  CUent/Server  Multimedia  on 
Token  Ring,"  Proceedings  of  18th  Conference  on 
Lo«d  Computer  Networks,  September  1993, 2-6. 

15.  Fouawi  A.  Tobagi,  "Carrier  Sense  Multiple^Access 
With  Message-Based  Priority  Functions,”  IEEE 
Trans,  on  Communications,  Vol.  COM-30,  Jan. 
1982,  pp.  185-200. 


379 


Priority  Communication  Schemes  on  Local  Area 
Networks  for  Multimedia  Traffic 

Amr  Elsaadany,  Mukesh  Singhal  and  Ming  T.  Liu* 

Department  of  Computer  and  Information  Science 
The  Ohio  State  University 
Columbus,  OH  43210 


Abstract 

In  this  paper  we  address  the  issues  related  to  the 
delivery  of  multimedia  streams  on  local  area  net¬ 
works.  Multimedia  integrates  voice  and  video  along 
with  text  and  images  into  existing  systems.  Tradi¬ 
tionally,  local  area  networks  were  designed  to  handle 
regular  data  traffic  which  are  bursty  in  nature  and  for 
which  variable  delay  is  acceptable.  Multimedia  traf¬ 
fic,  on  the  other  hand,  requires  constant  delay  in  ad¬ 
dition  to  fast  (or  real  time)  delivery.  Multimedia  traf¬ 
fic  also  requires  large  bandwidth  compared  to  regular 
traffic.  Since  local  area  networks  are  widely  in  use, 
their  modification  to  integrate  multimedia  streams  is 
very  important.  In  this  paper  we  propose  priority- 
based  communication  schemes  for  the  timely  deliv¬ 
ery  of  multimedia  traffic  on  local  area  networks.  We 
compare  the  performance  of  these  schemes  using  sim¬ 
ulation  techniques. 

Key  words:  Multimedia,  local  area  networks,  pri¬ 
ority. 

1  Introduction 

Multimedia  is  a  media  that  integrates  the  transmis¬ 
sion  of  voice  and  video  along  with  text  and 
into  existing  systems  [1,2, 3, 4, 5].  Digital  multime¬ 
dia  transmits  multime^a  inibrmation  digitally  and 
allows  them  to  be  manipulated  and  stored  on  a  com¬ 
puter  system.  It  also  allows  for  interactive  human 
interface.  Interactive  multimedia  allows  the  user  to 
interface  with  the  system  in  real  time  which  is  im¬ 
portant  for  education,  business,  entertainment,  and 
communications. 
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A  large  number  of  commercial  organizations  as  well 
as  unhfcrsities  use  some  type  of  local  area  network 
environment.  These  organizations  have  two  options 
for  adding  multimedia  capabilities.  One  option  is 
to  utilize  the  existing  networks  by  adding  some  de¬ 
vices  and/or  software  in  order  to  transmit  multime¬ 
dia  streams.  The  other  option  is  to  use  an  ATM  type 
network  (see  section  3.2).  ATM  is  designed  such  that 
vmce  and  video  can  be  transmitted  effectively  along 
with  data  packets.  ATM  switches  and  interfaces  will 
be  needed  which  would  add  a  lot  of  cost  to  these  or¬ 
ganizations. 

Eli  sting  local  area  networks  have  two  main  prob¬ 
lems  with  regard  to  the  integration  of  multimedia 
streams.  First,  the  existing  bandwidth  capability  for 
a  standard  LAN  does  not  support  multimedia  trans¬ 
mission  requirements.  Second,  there  is  no  explicit 
priority  mechanism  for  transmitting  data/stream  on 
LANs.  Multimedia  streams  must  be  received  at  the 
user/premnUtion  site  at  a  time  that  there  would  be 
no  interruption  (or  gap)  ftom  user’s  point  of  view 
(consider  a  moving  picture  presentation).  Note  that 
multimedia  streams  are  isochronous  and  require  a 
constant  delay  between  packets. 

This  paper  focuses  on  the  problems  associated 
with  supporting  multimedia  on  local  network  envi¬ 
ronments.  The  protocols  of  the  local  area  networks 
are  not  suitable  for  multimedia  traffic.  They  were  de¬ 
signed  to  handle  regular  data  traffic  which  are  bursty 
in  nature  and  for  which  variable  delay  is  acceptable. 
IVaditional  communication  protocols  for  locd  area 
networks  have  to  be  modified  to  suit  the  needs  of 
multime<fia  applications.  We  present  protocols  for 
priority-based  communications  on  Ethernets  to  allow 
timdy  defivery  of  multimedia  traffic  on  Ethernets  and 
compare  the  performance  of  the  possible  alternatives. 
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The  rest  of  the  p»pcr  “  organiied  as  follows:  In 
the  next  section,  we  present  daU  requirements  of 
multimedia  systems.  la  Section  3,  we  give  a  brief 
background  of  communication  networks.  Section  4 
presenU  two  techniques  for  priority-based  communi¬ 
cation  on  EtherneU.  In  Section  5,  we  present  a  sim¬ 
ulation  study  of  the  proposed  techniques.  FinaUy, 
Section  6  concludes  the  paper. 

2  Multimedia  Data  Require¬ 
ments 

All  digital  media  require  digital  end-to-end  trans¬ 
mission  of  multimedia  data  streams.  This  means  that 
the  communication  network  must  support  the  trans¬ 
mission  of  digitized  voice,  video  and  images.  The 
network  must  also  have  a  wide  bandwidth  to  sup¬ 
port  these  transmissions.  Not  aU  existing  networks 
have  sufficient  bandwidth  to  accommodate  the  needs 
of  all  kinds  of  multimedia  applications.  For  example, 
a  LAN  with  10  Mbps  bandwidth  may  be  able  to  pro¬ 
vide  limited  support  to  transfer  video  and  images  for 
some  multimedia  applications. 

Multimedia  applications  require  fast  processing 
and  small  visual  response  time.  Moreover  the  effect 
of  latency  in  tramsmitting  streams  between  stations 
should  be  minimized  or  eliminated. 

Moreover  the  amount  of  storage  required  by  mul¬ 
timedia  data  is  much  more  than  that  of  regular  data. 
A  640  X  480  24-bit  color  resolution  graphic  image,  for 
example,  takes  about  900KB  of  memory.  Most  com¬ 
mon  audio  CD  uses  16-bit  resoluticm  and  44.1KHz 
sampling  rate.  One  second  of  this  Ugh  quality  audio 
requires  176.4  kB  of  storage.  Vedio  is  composed  of 
a  stream  of  frames  (e.g.,  NTSC  uses  30  per  second). 
One  second  of  30  video  of  size  640  x  480  pixels 
and  24  bit  color  resolution  requires  about  27MBps 
bandwidth. 

Multimedia  data  compro^n  techniques  reduces 
the  amount  of  bandwidth  required  by  streams  such 
as  video.  In  addition,  the  amount  of  disk  storage  re¬ 
quired  for  multimedia  data  can  be  substantially  de¬ 
creased.  The  27MBp8  transfer  rate  required  for  the 
640  X  480  screen  would  be  reduced  to  550kBps  using 
the  MPEGl  standard  [6].  MPEGl  can  also  compress 
audio  by  a  factor  of  5-10. 

It  is  clear  that  the  amount  of  data  needed  to  repre¬ 
sent  video  digitally  places  tremendous  requirements 


on  storage,  transmission,  bandwidth  as  well  as  dis¬ 
play  capabilities  of  current  systems.  In  addition  to 
the  storage  and  bandwidth  requirements  for  multi- 
media  data,  there  are  some  other  problems  associ¬ 
ated  with  multimedia  such  as  the  suitability  of  exist¬ 
ing  network  protocols.  More  information  about  the 
properties  of  the  multimedia  data  types/streams  and 
the  requirements  of  multimedia  applications  can  be 
found  in  [7,8]. 

3  Communication  Network 
Background 

3.1  Local  Area  Networks 

Local  area  networks  (LAN)  exist  in  one  of  the  fol¬ 
lowing  architectures;  bus,  tree,  token  ring  and  FDDl 
(Fiber  Dual  Data  Interface)  ring  [9,10].  The  most 
widely  used  LAN  is  the  Ethernet  which  is  a  bus-based 
architecture.  This  type  of  network  typically  has  10 
Mbps  bandwidth  as  opposed  to  100  Mbps  for  FDDI. 

Local  area  network  bus  (non  token)  protocols 
are  based  on  broadcasting.  The  most  dominat¬ 
ing  medium  acce^  protocol  (MAC)  in  use  is  the 
CSMA/CD  (Carrier  Sense  Multiple  Access  with  Col¬ 
lision  Detection)  in  which  each  station  listens  to  the 
channel  while  transmitting.  In  case  a  collision  is  de¬ 
tected  during  transmission,  the  station  ceases  trans¬ 
mission  and  retries  after  some  (random)  period  of 
time.  This  protocol  requires  that  the  me^ge  size 
be  longer  than  twice  the  propagation  time  (in  order 
to  detect  collision  before  transmission  is  complete). 
It  also  use  binary  exponential  backoff  technique,  in 
which,  after  each  repeated  collision,  the  mean  value 
of  the  random  delay  is  doubled. 

One  other  MAC  that  is  widely  used  is  the  token 
bus  in  which  stations  on  the  bus  form  a  logical  ring 
with  a  token  (control  packet)  to  regulate  access  to 
the  medium.  When  a  station  receives  the  token,  it 
get  control  of  the  medium  for  a  specified  time.  When 
the  station  is  done,  or  time  expires,  it  passes  the  token 
to  the  next  station  in  the  logical  ring. 

LAN  topologies  are  based  on  sharing  the  band¬ 
width  between  stations.  Data  sent  are  assumed  to  be 
time-bdependent,  they  can  be  broken  bto  packets 
without  regard  to  their  order.  Also,  when  a  station 
is  usmg  the  network  for  transmission,  no  other  sta¬ 
tion  can  and  the  entire  bandwidth  is  assigned  to  it. 
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Options  for  Multimedia: 

To  overcome  the  problems  with  the  speed  and/or 
order  of  transmission  on  LAN,  several  alternatives  are 
being  explored.  Fast  Ethernet  is  one  way  to  solve  the 
bandwidth  problem  of  the  standard  Ethernet  and  it 
is  expected  to  be  10  times  wider.  It  may  retain  the 
CSMA/CD  MAC  protocol  to  allow  internetworking 
with  standard  Ethernet  LANs. 

Another  way  to  overcome  the  bandwidth  problem 
is  to  use  switching  hubs.  Switched  Ethernet  estab¬ 
lishes  a  single  point-to-point  LAN  between  each  work¬ 
station  and  a  high-capacity  switching  bub  [11].  This 
gives  each  workstation  its  own  LAN  with  aU  of  its 
bandwidth.  (Some  topologies  may  have  more  than 
one  workstation  per  LAN.)  However  the  switching 
bub  may  be  a  bottleneck  at  some  point.  That  is  why 
this  network  architecture  imposes  limits  on  the  num¬ 
ber  of  workstations  that  could  be  connected  to  the 
hub,  and  also  on  the  number  of  simultaneous  users. 

Other  options  include  using  FDD!  (running  over 
twisted  pair  for  a  short  distance)  to  increase  the  band¬ 
width  to  100  Mbps.  FDDI  te<^noiogy  could  be  ex¬ 
tended  to  support  the  timely  delivery  required  by 
multimedia  applications.  Isochronous  Ethernet  is  an¬ 
other  option  which  provides  isochronous  channels  to 
stations  equipped  with  isoENET  cvds  [12]. 


3.2  Switching  Networks 

Switching  networks  transfer  information  between 
source  and  destination  via  three  functions:  transmia* 
Sion,  multiplexing,  and  switching.  IVansmission  pro¬ 
vides  the  point-to-point  transfer  of  information.  Mul¬ 
tiplexing  uses  a  smgle  transmission  facility  (link)  for 
several  independent  channels.  Switching  uses  prop¬ 
erties  of  telecommunications  traffic  to  replace  a  fully 
meshed  network  interconnecting  all  pairs  of  users 
with  a  shared  substructure  providing  on  demand  con¬ 
nections,  that  is,  packets  can  be  assinged  to  channels 
based  on  the  address  information  in  the  header  of  the 
packets  themselves. 

Circuit  switching  networks  use  time  division  mul¬ 
tiplexing  (TDM)  where  bandwidth  is  multiplexed 
between  several  channels  with  assigned  amounts  of 
bandwidth.  Time  slots  within  a  frame  are  allocated 
to  the  channel  for  the  duration  of  the  service.  This 
type  of  networks  is  suitable  for  applications  that  re¬ 
quire  guaranteed  bandwidth  or  low  latency  such  as 
PCM  voice  and  constant  bit  rate  data  trt^c.  The 


mode  of  transfer  in  this  type  of  network  is  referred  to 
as  synchronous  transfer  mode  (STM). 

Packet  switching  networks  use  bandwidth  effi¬ 
ciently  to  suit  bursty  applications  such  as  file  trans¬ 
fers.  However,  the  delay  in  these  networks  is  unpre¬ 
dictable  and  the  latency  tends  to  be  high.  Packet 
switching  uses  statistical  multiplexing  which  dynam¬ 
ically  allocates  time  slots  to  incoming  channels  based 
on  demand.  In  contrast  with  synchronous  TDM,  the 
positional  significance  of  the  slots  (in  TDM)  is  lost 
and  hence  each  packet  has  to  carry  addressing  infor¬ 
mation  in  addition  to  data. 

ATM  (Asynchronous  Transfer  Mode)  uses  cell 
switching  which  uses  bandwidth  flexibly  and  effi¬ 
ciently  for  all  sorts  of  applications.  For  constant  rate 
applications,  a  guaranteed  number  of  cells  per  sec¬ 
ond  can  be  aUoeated  and  any  unused  cell  slots  can  be 
allocated  (on  demand)  to  bursty  applications.  In  ad¬ 
dition,  the  number  of  virtual  channels  carrying  these 
cells  can  vary  as  well  as  the  rate  of  each  channel. 

In  cell  switching  technology,  a  cell  is  a  53  byte 
fixed  length  packet  with  5  bytes  for  header  (contain¬ 
ing  routing  and  quality  of  service  information)  and 
48  bytes  for  data  (payload  section)  [13].  This  fixed 
length  celb  are  better  suited  for  high  speed  switching 
because  it  enables  simpler  implementation  of  switches 
and  provides  predictable  system  behavior. 

The  asynchronous  nature  of  ATM  comes  from  the 
fact  that  cells  are  assigned  asynchronously  to  any  ser¬ 
vice  based  on  its  needs.  This  is  facilitated  by  the  fact 
that  eadi  cell  is  addressed  independently  to  any  des¬ 
tination.  In  this  mode  of  transmission,  there  is  no 
notion  of  owning  a  time  slot  on  periodic  basis. 

Although  existing  wide  networks  (WAN)  can  be 
used  by  some  multimedia  applications,  these  WAN- 
based  applications  would  suffer  from  existing  prob¬ 
lems  such  as  the  varymg  network  delays.  When  it 
become  widely  available,  ATM  will  be  a  suitable  tech¬ 
nology  that  has  the  high  bandwidth  and  low  latency 
requirements  for  many  multimedia  applications. 


4  Priority  Schemes 

As  mentioned  before,  our  work  focuses  on  the  prob¬ 
lems  associated  with  supporting  multimedia  services 
on  local  network  environments.  The  protocols  for 
regular  data  transfer  on  the  local  area  networks  are 
not  suitable  for  multimedia  traffic  and  they  have  to 
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be  modified  to  suit  multimedia  applications.  These 
protocols  were  designed  to  handle  regular  data  traffic 
which  is  bursty  in  nature  and  for  which  variable  delay 
is  acceptable.  We  present  priority-based  communica¬ 
tion  protocob  for  allowing  timely  delivery  of  multi- 
media  traffic  on  local  area  networks.  We  focus  our 
attention  to  the  problems  a^ciated  with  supporting 
multimedia  traffic  on  with  local  area  bus  (Ethernet) 
as  opposed  to  token  ring  networks  [14]. 

The  current  medium  acc^  bus  protocol  does  not 
provide  priority  for  transfer  of  data.  Stations  on  the 
bus  use  the  CSMA/CD  protocol  to  compete  for  bus 
bandwidth.  Thb  means  packets  can  indberiminately 
collide  and  get  retransmitted.  Thb  medium  acce^ 
protocol  b  suitable  for  regular  data  traffic  but  not  for 
multimedia  traffic.  We  propose  two  priority  schema 
that  add  some  sense  of  priority  to  data  traffic  on  the 
bus.  They  support  two  leveb  of  priority:  high  priority 
(for  multimedia  or  real-time  traffic)  and  low  priority 
(for  regular  data). 


Tm  Tr  Tm  Tr 
Figure  1.  Bus  Time 


4.1  Bus-Time  Multiplexing  Priority 
Scheme 


Bus-time  multiplexing  scheme  relies  on  message  pa» 
ing  to  support  two  leveb  of  priority.  Before  a  station 
sends  a  "high  priority"  traffic  (for  a  multimedia  ses¬ 
sion),  it  informs  every  other  station  of  its  intention 
so  that  they  would  abstain  from  sending  "low  prior¬ 
ity"  traffic  for  a  period  of  time.  Thb  b  accomplbhed 
by  broadcasting  a  request  me^ge  that  includes  the 
amount  of  time  that  the  station  needs  (i.e.,  the 
sion  length).  During  thb  time  period,  only  high  pri¬ 
ority  traffic  b  allowed  to  use  the  bus. 

Since  the  request  menage  will  compete  for  the  bus 
with  other  traffic,  the  scheme  has  to  ensure  that  thb 
message  gets  succe^fully  transmitted  before  the  high 
priority  traffic  period  starts. 


When  stations  receive  a  message  indicating  that 
high  priority  traffic  need  to  be  sent  by  a  station,  they 
stop  sending  low  priority  traffic  at  once.  Stations 
record  the  time  at  which  they  will  be  allowed  to  send 
regular  traffic.  Thb  time  would  be  equivalent  to  the 
current  time  plus  the  length  of  the  session  (which  b 
included  in  the  request  message).  Stations  also  keep  a 
count  of  the  number  of  multimedia  sessions  currently 
in  progr^.  Whenever  a  station  receives  a  request 
message,  it  increment  thb  count  by  one. 

Within  a  high  priority  period,  if  another  station 
wants  to  start  a  multimedia  session,  it  can  use  the 
bus  simultaneously  since  it  knows  that  the  bus  b  be¬ 
ing  used  for  high  priority  traffic.  However,  the  sta¬ 
tion  has  to  send  a  (request)  message  to  other  sta¬ 
tions.  Thb  m^age  will  be  used  to  update  the  time 
at  which  the  high  priority  period  will  terminate.  In 
addition,  stations  will  increment  the  number  of  cur¬ 
rent  multimedia  sessions  by  one.  During  thb  time 
period,  high  priority  traffic  compete  for  the  bus  us¬ 
ing  the  CSMA/CD  medium  access  protocol  (but  they 
do  not  compete  with  low  priority  traffic). 

After  a  station  has  finbhed  sending  its  high  pri¬ 
ority  traffic,  it  broadcasts  a  completion  message  in¬ 
dicating  that  the  number  of  multimedia  sessions  b 
decremented  by  one.  Again  the  scheme  has  to  ensure 
that  the  completion  message  gets  delivered  even  after 
it  collide  with  other  traffic. 

Thus  the  bus  b  time  multiplexed  between  high  pri¬ 
ority  and  low  priority  traffic,  as  illustrated  by  Figure 
1,  wh^  Tm  b  time  period  used  by  multimedia  (high 
priority)  traffic  and  Tr  b  time  period  during  which 
regular  (low  priority)  traffic  can  be  sent. 

The  period  (Tm)  during  which  the  bus  time  b  dedi¬ 
cated  to  multimedia  traffic  b  measured  from  the  start 
of  the  high  priority  traffic  session(s).  Thb  period  ends 
when  the  count  of  multimedia  sessions  goes  down  to 
zero  OT  if  Tm  exceeds  a  pre-determined  maximum 
limit.  If  Tm  exceeds  this  limit,  regular  traffic  will 
be  allowed  to  use  the  bus.  The  ratio  Tm/TV  need  to 
be  chosen  carefully  to  insure  fairness  to  regular  data 
traffic. 

The  number  of  simultaneous  multimedia  sessions 
has  to  be  limited,  otherwise,  they  would  interfear 
with  each  other  producing  low  quality  in  addition  to 
increasing  the  regular  data  traffic  delay.  This  limita¬ 
tion  is  dependent  on  the  amount  of  available  band¬ 
width  and  the  nature  of  the  multimedia  applications. 

Thb  technique  should  result  in  better  multimedia 
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traffic  performance  over  the  non-prioritized  bus  pro¬ 
tocol,  but  regular  data  traffic  will  suffer  some  delay. 
This  delay  could  be  acceptable  to  a  user  sending  regu¬ 
lar  data.  On  the  other  hand,  a  delay  in  video  frames, 
for  example,  may  result  in  an  unacceptable  presenta¬ 
tion  quality. 


4.2  Station  Multiplexing  Scheme 

In  the  station  multiplexing  scheme,  each  station  keeps 
status  information  about  the  transmission  requests 
of  all  other  stations.  Using  this  status  information, 
each  station  will  be  able  to  make  decision  to  send 
packets  on  the  bos.  Each  station  is  still  required  to 
send  a  request  message  before  starting  its  multime* 
dia  session  (i.e.,  high  traffic  session),  but  stations  are 
not  required  to  send  a  message  after  completing  their 
sessions. 

In  this  scheme,  each  station  maintains  a  data  struc¬ 
ture  that  has  an  entry  for  each  station.  The  entry  for 
a  station  contains  the  time  of  the  latest  transmission 
request  made  by  that  station  for  high  priority  traffic. 
An  entry  for  a  station  is  updated  when  a  (request) 
message  is  received  indicating  that  it  wants  to  start 
its  multimedia  session. 

All  stations  use  a  fixed  length  quantum  (Tq)  for 
high  priority  traffic.  A  station  uses  the  bus  for  this 
quantum  and  renews  its  request  for  another  after  the 
current  quantum  expires.  A  station  wanting  to  start 
a  session  or  renew  its  request  for  another  quantum, 
compares  the  timestamps  in  its  local  structure.  The 
station  that  corresponds  to  the  smallest  timestamp  is 
the  one  that  can  use  the  bus  next  (after  the  current 
quantum  expires). 

A  station  can  find  if  the  current  quantum  has  ex¬ 
pired  by  comparing  the  difference  between  the  latest 
(highest)  timestamps  in  its  local  structure  and  the 
current  time  with  the  default  session  length  quantum. 
If  the  current  time  minus  the  value  of  the  latest  times¬ 
tamp  is  less  than  or  equal  the  value  of  Tq,  the  station 
may  proceed  with  its  request  immediately.  Other¬ 
wise,  the  station  tries  whenever  the  current  quantum 
expires. 

In  this  scheme,  the  bus  time  is  still  multiplexed 
between  high  priority  and  low  priority  traffics,  but  in 
addition,  the  Tm  period  is  further  divided  into  small 
time  quanta  (of  duration  Tq)  and  each  station  uses 
a  quantum  (if  needed)  based  on  the  latest  timestamp 
criterion  stated  above.  This  would  improve  perfor¬ 


mance  further  since  the  competition  between  stations 
(during  Tm)  is  regulated.  In  other  words,  this  ap¬ 
proach  further  reduces  the  possibility  of  collisions. 

The  basic  idea  is  that  stations  that  need  to  send 
high  priority  traffic  will  use  the  bus  in  a  last  recently 
used  order.  The  station  with  the  oldest  (smallest) 
timestamp  will  be  allowed  to  use  the  bus  once  the 
current  Tq  expires. 

If  two  stations  send  their  request  messages  at  the 
same  time,  these  messages  will  collide.  In  such  cases, 
one  station  will  backoff  its  transmission  of  request 
message  and  the  other  will  proceed.  (Station  num¬ 
bers  can  be  used  for  tie  breaking.) 

As  in  the  previous  scheme,  the  period  (Tm)  during 
which  the  bus  is  dedicated  to  multimedia  traffic  has 
a  maximum  length  from  the  start  of  the  high  priority 
traffic  ses8ion(s).  If  Tm  exceeds  this  limit,  regular 
traffic  will  be  allowed  to  use  the  bus.  Again,  the  ratio 
Tm/Tt  need  to  be  chosen  carefully  to  ensure  fairness 
to  regular  data  traffic. 

A  variation  of  this  scheme  is  round  robin  scheme, 
where  stations  are  served  in  a  pre-defined  order  and 
for  a  fixed  period  of  time.  This  scheme  is  similar  to 
a  token  based  scheme,  where  stations  pass  a  token 
among  themselves  in  a  pre-defined  order  and  only 
the  station  that  has  the  token  can  use  the  bus  for  its 
high  priority  traffic  for  a  predefined  period.  When 
timer  expires,  station  passes  the  token  to  the  next 
one.  While  this  scheme  reduces  the  competition  be¬ 
tween  stations  trying  to  send  high  priority  traffic,  it 
may  result  in  an  unacceptable  response  time  for  some 
demanding  users. 


5  Simulation  Results 

An  event-driven,  discrete  time  simulators  of  the  pro¬ 
posed  priority  schemes  was  written  to  study  their  per¬ 
formance  under  various  mixes  of  high  priority  and 
low  priority  traffics.  The  simulators  were  written  in 
CSIM. 

The  performance  measure  studied  was  the  mean 
response  time  or  average  end-to-end  delay.  It  is  the 
time  mtwval  between  the  instant  a  packet  u  ready 
to  be  transmitted  and  the  instant  the  packet  is  deliv¬ 
ered. 

We  studied  the  performance  of  the  following  three 
schemes: 
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•  A  no  priority  scheme:  this  schemes  does  not  give 
priority  to  muJtimedi*  traffic. 

•  An  absolute  priority  scheme:  this  schema  giv“ 
absolute  priority  to  multimedia  traffic.  pri¬ 
ority  traffic  had  to  wait  whenever  there  is  high 
priority  traffic  to  be  sent. 

•  Bus-time  multiplexing  scheme:  this  schemes  di¬ 
vides  the  time  into  two  intervals.  One  during 
which  only  multimedia  traffic  can  be  sent  and 
another  where  both  traffic  typ«  can  be  sent. 


a 


The  first  scheme,  namely  the  non  priority  scheme 
was  studied  to  compare  its  performance  with  the 
other  priority  schemes.  This  scheme  basically  sim¬ 
ulates  an  Ethernet/bus  protocol.  It  is  expected  that 
the  average  end-to-end  delay  for  this  scheme  to  be 
high  and  not  suitable  for  multimedia  traffic. 

The  abolute  priority  works  as  follows.  Each  station 
gives  higher  priority  to  multimedia  traffic.  Any  low 
priority  packects  will  not  be  transmitted  as  long  as 
there  are  some  high  priority  traffic  need  to  be  trans¬ 
mitted.  This  scheme  gives  the  best  performance  av¬ 
erage  r^ponse  time  (a  lower  bound  on  delay)  for  high 
priority  traffic.  On  the  other  hand,  it  wUl  result  in 
the  worst  performance  for  low  priority  traffic. 

The  simulator  used  the  parameters  of  a  10  Base 
5  Ethernet  that  has  a  bandwidth  of  10  Mbps.  The 
maximum  propagation  delay  is  2.5  micro  seconds.  A 


packet  of  sise  IK  biU  have  100  micro  seconds  trans¬ 
mission  time.  Unless  otherwise  stated,  the  proba¬ 
bility  that  the  next  request  for  the  bus  is  for  high 
priority  traffic  equab  0.5. 

Figura  2  and  3  show  the  mean  response  time  (in 
ms)  for  the  three  schemes  as  the  number  of  work¬ 
stations  (multimedia  sessions)  increase.  In  Figure  2, 
packet  sim  is  IK  bits,  while  in  Figure  3  the  packet 
sise  is  8K  bits. 

We  observe  that  the  absolute  priority  scheme  give 
the  best  results  for  high  priority  traffic.  It  improves 
the  response  time  of  high  priority  traffic  by  a  about 
60  percent.  However,  we  found  that  the  performance 
of  low  primity  traffic  performance  was  severely  de¬ 
graded.  It  degraded  the  performance  of  regular  traffic 
by  a  factor  <rf  35.  In  addition,  it  completely  shut  off 
regular  traffic  as  the  number  of  stations  (multimedia 
scions)  increased  beyond  ten. 
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The  b»-time  multiplexing  scheme  produced  better 
overall  results  for  both  low  priority  and  high  priority 
traffic  than  a  non-prioritized  scheme  or  an  absolute 
priority  scheme.  It  improved  the  response  time  for 
high  prkwity  traffic  by  a  about  35  percent,  and  de¬ 
graded  the  performance  of  regular  traffic  by  only  a 
factor  of  6. 

Figure  4  shows  the  probability  of  discarding  high 
priority  packects  due  to  their  arrival  after  their  dead¬ 
line  for  the  three  scheme  under  study.  We  assumed 
that  packet  size  is  IK  biU  and  a  high  priority  packet 


877 


misses  its  deadline  (i.e.,  is  of  no  value  to  the  applicar 
tion)  if  it  does  not  reach  its  destination  in  100  ms- 
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We  observe  that  the  absolute  priority  scheme  re¬ 
duces  the  probability  of  discarding  Ugh  priority 
packet  by  a  factor  of  S.  The  bus-time  multiplexing 
scheme  reduces  the  probability  of  discarding  high  pri¬ 
ority  packet  by  a  factor  of  3.  Note  that  this  is  quite 
an  improvement  over  the  no-priority  scheme  that  has 
a  relatively  high  deadlme  miss  rate  which  adversely 
affects  the  quality  of  service. 


a 


Figure  5  shows  the  results  for  a  system  where  80 
percent  of  the  transmission  requests  are  for  high  pri- 
ority  traffic  and  20  percent  for  regular  traffic.  By 
comparing  Figure  2  and  Figure  $  we  observe  that  the 
performance  of  high  priority  traffic  suffers  when  the 
fraction  of  high  probability  traffic  is  higher.  This  is 
due  to  the  fact  that  there  is  more  contention  among 
high  priority  requests  on  the  bus. 

We  observe  that  the  absolute  priority  scheme  still 
give  the  best  performance  for  the  high  priority  traffic. 
However,  the  bus-time  multiplexing  scheme  gives  the 
best  overaU  performance  for  both  types  of  traffics. 

6  Conclusions 

TVaditional  medium  access  protocols  for  Ethrenet  do 
not  support  the  concept  of  priority  for  data  traffic. 
Stations  along  the  bus  equally  compete  for  bus  band¬ 
width.  This  means  that  packets  can  mdiscriminately 
collide  and  get  retransmitted.  This  medium  access 
protocol  is  suitable  for  regular  data  traffic  but  not 
for  multimedia  traffic.  The  problem  with  multimedia 
streams  is  that  they  are  isochronous  in  nature  and 
they  need  to  be  delivered  in  real  time.  Thus  a  mix¬ 
ture  of  (multimedia  and  regular)  traffic  on  a  LAN 
bus  would  not  satisfy  this  requirement.  Multimedia 
traffic  need  to  be  transmitted  at  higher  priority  than 
regular  data  traffic. 

This  paper  focused  on  supporting  timely  delivery 
of  multimedia  traffic  on  local  area  networks.  We 
introduced  two  schemes,  the  bus-time  multiplexing 
scheme  and  the  station  multiplexing  scheme,  for  pri¬ 
ority  transmission  of  data  on  an  Ethernet.  These 
schemes  add  a  sense  of  priority  to  the  traffic  on  the 
bus. 

The  bus-time  multiplexing  scheme  supports  two 
leveb  of  priority  (high  priority  and  low  priority)  and 
multiplexes  the  bus  time  between  the  two  traffic 
types.  It  relies  on  sending  a  message  to  inform  all 
stations  that  bus  should  be  used  for  high  priority  traf¬ 
fic  for  some  period  of  time  during  which  low  priority 
traffic  are  not  transmitted.  This  technique  results 
in  a  better  multimedia  traffic  performamce  over  the 
no-priority  bus  protocol  but  regular  data  traffic  will 
sufier  some  delay.  This  delay  could  be  acceptable  to 
a  user  sending  regular  data.  On  the  other  band,  a 
delay  in  video  frames,  for  example,  may  result  in  an 
unacceptable  presentation  quality. 

In  the  station  multiplexing  scheme,  the  bus  time  is 
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ther  iiince  the  competition  betw«®  sUtions  dumg 
the  high-priority-period  u  regulated  which  m  effee 
reduce  the  number  of  collisions. 

The  two  schemes  presented  here  reserve  bus  time 
for  a  specified  time  duration,  while  the  scheme  pre¬ 
sented  in  [15]  provides  message-based  priority  func¬ 
tions.  At  the  end  of  each  transnuMion  each  sUtion 
evaluates  its  priority  compared  to  the  priority  of  the 
cunent  transmission.  In  our  schemes,  during  the  time 
r<»erved  for  high  priority  traffic,  there  is  no  need  for 
request/reservation  mewages  which  in  effect  reduce 
the  protocol  overhead. 

Simulation  resulU  indicate  that  the  bus-time  multi¬ 
plexing  scheme  give  the  best  overaU  performance  for 
both  types  of  traffics  compared  with  a  non-piioritised 
scheme  or  a  scheme  that  gives  ^isolute  priority  to 
multimedia  traffic. 
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Abstract 

Fonnal  methods  for  protocol  design  have  emerged  since  the  last  decade  due  to  the 
recogmtion  of  the  limitations  of  informal  techniques  by  many  researchers.  Experience 
has  shown  that  informal  techniques  that  use  ad  hoc  approaches,  often  produces  systems 
with  errors  and  undesirable  behaviors.  On  the  other  hand,  by  using  formal  approaches, 
many  phases  of  protocol  design  can  be  automated,  thereby  miTiiTnigiTig  the  occurrences 
of  errors  and  undesirable  behaviors.  Formal  description  techniques  (FDTs),  which  give 
a  precise  deiimtion  of  the  specified  protocol  and,  consequently,  allow  for  formal  methods 
to  examme  the  protocol  correctness  and  performance,  have  become  the  basis  of  formal 
methods  for  protocc4-design.  In  this  paper,  besides  the  standardized  FDTs,  such  as 
LOTOS,  Estelle  and  SDL,  several  other  FDTs  in  various  models  are  presented  and 
compared.  For  ease  of  comparison,  a  common  example,  the  alternate  bit  protocol  ( ABP), 
is  used  throughout  this  paper  to  demonstrate  how  various  FDTs  can  be  used  in  protocol 
specifications. 


^Research  reported  herein  was  supported  by  U.S.  Army  Research  Office,  under  contracts  No.DAAL03-91- 
G>0093  and  No.  DAAL03-92-G*0184.  The  views,  opinions,  and/or  findings  contained  in  this  paper  are  those 
of  the  authors  and  should  not  be  construed  as  an  official  Department  of  the  Army  position,  policy  or  decision. 
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1  Introduction 


A  protocol  is  a  set  of  rules  governing  the  exchange  of  messages  between  entities  in  a  computer 
communication  network.  At  the  lowest  level,  protocols  may  prescribe  how  information  is  to  be 
transmitted  and  received  over  a  physical  medium,  and  how  that  information  is  to  be  physically 
represented  on  the  medium.  At  higher  levels,  protocols  aim  to  overcome  inherent  unreliability 
in  low  levels,  to  prevent  congestion  and  deadlocks,  to  control  the  flow  of  information,  and  to 
provide  mechanisms  for  delivery,  addressing  and  routing  of  messages.  At  still  higher  levels, 
protocols  may  provide  services  for  transferring  files  between  physically  separated  computers, 
for  enabling  communication  between  incompatible  terminals,  for  ensuring  security  m  data 
transmission,  etc.  Consequently,  in  computer  networks,  protocols  are  key  components  and 
generally  complex.  They  must  work  correctly  for  the  system  to  provide  expected  services. 

Moreover,  since  protocols  define  the  interaction  between  communicating  entities  running 
in  parallel  and  residing  at  different  nodes  of  the  network,  their  design  can  be  remarkably  hard, 
much  harder  than  it  is  to  write  a  sequential  program.  Unfortunately,  when  the  design  of  a 
new  protocol  is  complete,  the  designers  usually  have  little  trouble  convincing  themselves  that 
it  is  trivially  correct.  As  a  result,  the  designers  usually  decides  to  trust  their  instincts  and 
foregoes  the  formal  proofs.  Subtle  logical  flaws  in  a  design  thus  get  a  chance  to  hide,  and 
inevitably  find  the  worst  possible  moment  in  the  lifetime  of  the  protocol  to  reveal  themselves. 

Because  of  the  complexity  of  protocol  software,  experience  has  shown  that  the  use  of  infor- 

t-*- 

mal  techniques  in  protocol  development  often  produces  systems  with  errors  and  undesirable 
behaviors;  thus,  it  has  been  recognized  that  good  software  engineering  techniques  are  needed 
for  the  implementation  and  maintenance  of  these  protocol  software  and  systems.  Conse- 
quently,  formal  methods  for  protocol  design  have  emerged  since  the  last  decade.  Using  formal 
approaches,  a  protocol  is  represented  by  a  formal  model  (or  interchangeably,  a  formal  specifi¬ 
cation).  Analytic  methods  can  then  be  used  to  examine  logical  correctness  and  performance 
of  the  protocol  before  it  is  actually  implemented.  This  methodology  has  been  proved  to  be 
so  effective  in  identifying  many  protocol  design  errors  that  the  discipline  in  this  area  is  called 
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protocol  engineering  [1]. 

Protocol  engineering  includes  many  phases:  protocol  specification,  protocol  validation, 
conformance  testing,  protocol  conversion,  etc.  Among  them,  protocol  specification  is  the  basis, 
eiround  which  all  other  phases  of  protocol  engineering  evolve.  In  protocol  engineering,  FDTs 
(formal  description  techniques)  are  used  for  protocol  specification  such  that  subsequent  formal 
protocol  analysis  and  verification  can  be  performed.  So  far,  m2Lny  FDTs  have  been  proposed 
and  examined  by  many  researchers  and  different  opinions  on  the  strength  and  weakness  of 
various  FDTs  exist.  In  [2],  it  is  pointed  out  that,  in  general,  an  FDT  that  is  suitable  for 
protocol  specification  must  be  able  to  provide  a  basis  for: 

•  the  development  of  unambiguous,  clear  and  concise  specifications. 

•  the  verification  of  specifications. 

•  the  functional  analysis  of  specifications. 

•  the  development  of  implementations  from  specifications. 

•  the  determination  that  an  implementation  conforms  to  its  specification,  i.e.  conformance 
testing. 


Furthermore,  in  [3],  it  is  pointed  out  that  a  good  FDT  should  contain  features  u  follows: 

•  broad  functional  coverage  such  as  concurrent  aspects,  data  descriptions,  etc. 

•  formal  definition  such  as  formally  described  syntax  and  interpretation  models,  etc. 

•  good  human  orientation  such  as  readability,  etc. 

•  high  expressive  power. 

•  structuring  capability  and  good  reusability. 

•  supporting  tools  such  as  graphical  input  interface,  etc. 
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In  fact,  since  the  widespread  acceptance  of  the  OSI  reference  model  and  its  standardized 
protocols,  a  great  deal  of  research  efforts  and  activities  in  protocol  engineering  and  FDTs 
have  been  made  to  develop  standardized  FDTs.  The  aforementioned  six  features  have  been 
the  targets  for  most  of  them. 

The  FDTs,  which  have  been  proposed  and  evaluated  by  various  researchers  and  organiza¬ 
tions,  can  be  categorized  according  to  the  specification  models  they  use  as  follows  [1,  4]: 

•  state  transition  models  -  a  communication  protocol  basically  consists  of  event-driven 
entities  that  communicate  with  each  other  through  message  passing.  The  behavior  of  an 
entity  can  be  described  in  terms  of  the  actions  (or  state  transitions)  that  the  entity  takes 
in  esponse  to  ei  :;rnal  and  internal  events.  State  transit  nodels  provide  the  simplest 
models  for  describing  protocol  entities.  The  advantage.  these  models  are  that  they 
are  simple  and  many  general  properties  of  a  protocol  can  be  verified.  However,  they 
are  not  suitable  for  describing  complex  protocols  since  they  involve  too  many  states 
and  transitions.  Models  falling  into  this  category  include  finite-state  automata,  form^ 
grammars,  and  Petri  nets  and  their  derivatives. 

•  programming  models  -  a  communication  protocol  executes  an  algorithmic  procedure 

which  can  be  described  using  a  language  notation  such  as  a  high  level  programming 

«* 

language.  In  general,  a  protocol  description  in  these  models  is  difficult  to  analyze  for 
correctness.  Efforts  to  prove  the  correctness  of  the  program  (the  safety  and  liveness 
properties)  far  exceed  those  required  for  developing  the  program,  and  its  correctness 
proof  usually  depends  heavily  on  human  ingenuity  and  is  hard  to  automate. 

•  hybrid  models  -  these  me  els  combine  the  features  of  the  transition  models  and  pro¬ 
gramming  language  models  for  describing  protocols.  In  these  models,  state  transition 
systems  are  augmented  with  variables  and  program  fragments  to  give  them  added  power. 
An  example  is  the  addition  of  such  features  as  variables  and  program  fragments  to  finite 
state  machines,  and  thsv  are  called  extended  finite  state  machines  (EFSM).  A  model  of 
this  type  can  capture  th  nain  feature  of  a  protocol  using  a  small  number  of  states,  while 
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the  variables  and  program  fragments  are  used  in  capturing  the  program-Hke  aspects  of 
the  protocol. 


Each  category  has  its  inherent  advantages  and  disadvantages.  In  this  paper,  several  FDTs 
in  aJl  three  categories,  are  briefly  described  and  compared. 

The  rest  of  this  paper  is  organized  as  follows:  Section  2,  Section  3  and  Section  4  describe 
various  FDTs  in  state  transition  models,  programming  language  models  and  hybnd  models, 
respectively;  in  Section  5,  conclusions  are  presented. 


2  ^tate- Transition  Models 

2.1  Finite-State  Automata  (FSA) 

The  FSA  model  is  one  of  the  earliest  formal  models  applied  to  protocols.  Ever  since  Lynch 
(in  1968)  [5]  and  subsequently  Bartlett  et  al.  (in  1969)  [6]  used  FSA  for  specifying  the 
Alternating  Bit  Protocol  (ABP),  the  number  of  formal  models  for  protocol  specification  has 
increased  at  a  rapid  rateT  The  ABP  has  since  then  become  a  classical  example  and  been 
used  extensively  by  other  models  to  illustrate  their  feasibflity  in  protocol  specification  and 
verification.  Throughout  this  paper,  ABP  wifi  be  used  as  an  example  to  show  how  each  FDT 

can  be  used. 

FSA  models  are  based  on  the  observation  that  protocols  consist  largely  of  relatively  simple 
processing  activities  in  response  to  a  number  of  events  such  as  commands  from  the  user, 
message  arrivals  from  another  entity,  and  internal  timeouts.  Therefore,  finite-state  automata 
with  such  events  forming  their  transitions  are  a  natural  model  for  specifying  communication 
protocols.  The  basic  approach  is  to  specify  the  communication  system  as  a  collection  of 
finite-state  automata,  each  describing  the  behavior  of  a  communicating  entity. 

In  this  model,  a  protocol  is  represented  by  a  network  of  communicating  finite-state  au- 
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tomata  and  channels  between  protocol  entities  are  modeled  by  FIFO  quei  Each  state 
of  a  finite-sta^e  automaton  corresponds  to  a  different  control  stage  of  the  entity  ^presents. 
Each  transition  of  a  automaton  is  labeled  with  either  an  input  event  that  enables  the  transition 
or  an  output  event  that  takes  place  as  part  of  the  transition. 


In  Fig.  1,  an  example  is  shown  how  FSA  is  used  to  specify  the  Alternating  Bit  Protocol 
(ABP).  This  protocol  provides  reliable  transmission  of  data  from  one  communicating  entity 


Figure  1:  ABP  ra  FSA  Model 


(called  the  sender)  to  the  other  (called  the  receiver).  In  Fig.  1,  entity  is  the  sender  and 
entity  P\,  is  the  receiver.  Data  are  divided  into  frames,  and  frames  are  transmitted  one  at 
a  time.  Note  that  the  channels  between  these  two  entities,  which  are  not  shown  in  Fig.  1, 
are  assumed  to  be  FIFO  queues.  The  characteristics  of  the  channels  are:  they  can  be  noisy 
and  data  can  be  garbled  but  never  lost.  Garbled  data  will  be  detected  and  recovered  by  the 
protocol.  The  error  detection  is  done  by  checking  the  sequence  control  bit  of  the  header  of 
each  frame.  Under  normal  transmission  (without  error),  the  sequence  control  bit  of  each  frame 
header  should  alternate  between  0  and  1  for  successive  frames.  If  the  receiver  detects  an  out 
of  sequence  frame,  it  sends  a  negative  acknowledgment  to  ask  for  re-transmission.  Otherwise, 
each  correctly  received  frame  is  explicitly  acknowledged.  The  negative  acknowledgment  is 
signaled  by  repeating  the  acknowledgment  of  the  last  acknowledged  frame.  Each  data  frame 
is  retransmitted  until  a  positive  acknowledgment  is  received.  Thus,  in  Fig.  1,  P^  sends  data 
frames  DO  and  D1  alternately  to  Pj,.  For  each  data  frame  sent  by  P®,  an  acknowledgment, 
AO  for  DO  and  Al  for  D1  respectively,  is  sent  by  P^.  The  protocol  user  at  P^  executes  IN  to 
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„quest  sending  of  n  date  frame  and  when  a  data  frame  arrives  at  the  other  end.  ft  executes 
OUT  to  pass  the  data  frame  to  the  user  at  ft.  Note  that  denotes  the  reception  of  a  data 
frame  or  acknowledgment  and  denotes  the  sending  of  a  data  frame  or  acknowledgment. 

Formally,  a  protocol  P  in  this  model  is  defined  as  a  set  of  communicating  protocol  entities 
and  a  protocol  entity  is  defined  as  follows. 

A  Protocol  Entity  P*  is  a  five-tuple  (g,  A,(5,i,/),  where: 

1.  q  is  the  set  of  states  in  P*. 

2.  A  is  the  finite  set  of  transitions  in  Px* 

3.  S  is  the  transition  function  of  ft  which  maps  ,  X  UA  into  r,  if  d(a.,t)  =  at. 
where  a.  €  J.at  €  !,  and  t  €  A,  is  called  the  starting  state  of  t  and  as 
is  the  ending  state  of  t.  Note  that  a  receive/read  transition  t.  is  said  to  be 
executable,  only  when  the  current  state  of  ft  is  the  starting  state  of  f.  and 
the  message  to  be  received/read  is  already  in  the  incoming  channel  to  P.. 

4.  i  is  the  initial  state  oi  Px* 

5.  /  is  the  set  of  the  final  states  in  P..  Note  that  for  a  typical  non-terminating 
protocol,  /  usually  has  only  one  element,  t,  which  is  the  initial  state  of  P.. 

Bochmann  P)  used  an  FSA  model  to  analyze  the  ABF  and  the  X.25  call  setup  and  clearing 
procedures.  West  and  Zafiropnlo  [S]  used  an  automated  technique  to  analyze  the  X.21  and 
found  a  number  of  unspecified  reception  errors  in  the  1976  version,  which  were  subsequently 
corrected  in  the  1980  version.  Gouda  and  his  assoaates  |9,  10,  11)  used  a  network  of  com 
municating  FSA  to  model,  analyze  and  synthesize  protocols.  Lee  and  Lai  [12]  have  used  a 
relational-algebra  approach  to  represent  an  FSA  as  a  transition  table.  On  this  basis,  the  well- 
known  theory  in  relation^  database  can  be  used  to  derive  the  global  state  transitions  of  the 
system.  Furthermore,  the  logical  errors  of  protocols  can  be  formulated  in  terms  of  relational 
algebra.  This  approach  have  be«i  implemented  on  the  INGRES  database  system  and  apphed 
to  the  validation  of  several  protocols  including  the  X.21. 
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A  l:raitation  of  the  FSA  model  is  that  aU  necessary  information  must  be  represented  by 
explicit  states.  For  example,  there  must  be  states  and  events  to  handle  each  possible  sequence 
number.  For  complex  protocols,  the  number  of  states  required  can  be  very  large,  thereby 
creating  the  so-called  state  explosion  problem. 


2.2  Formal  Grammars 

Formal  languages  and  the  grammars  that  define  them  are  a  type  of  the  state-transition  model. 
If  one  views  the  sequence  of  input  and  output  of  an  FSA  as  sequences  of  a  formal  language,  one 
can  define  the  formal  grammar  that  would  produce  all  vafid  sequences.  There  is  a  weU-known 
correspondence  between  such  grammars  and  various  types  of  automata  that  wiU  recognize  (or 
generate)  all  valid  sequences  of  the  language. 

Harangozo  [13]  used  regular  grammars  to  specify  the  HDLC  protocol  and  extended  the 
model  to  handle  sequence  numbers  by  indexing  the  production  rules  of  the  grammar.  Using 
context-free  grammars,  Teng  and  Liu  [14,  15,  16]  developed  a  Transition  Grammar  (TG) 
model  for  the  design  and  implementation  of  communic..  i,ion  protocols. 

In  the  TG  grammar,  a  protocol  is  represented  by  a  set  of  formal  grammars.  As  formal 
grammars  are  capable  of  defining  a  language,  the  idea  is  to  come  up  with  a  set  of  production 
rules  tliat  define  afi  the  legal  protocol  action  sequences.  Each  entity  or  channel  of  the  protocol 
in  the  TG  model  is  described  by  a  regular  gr  mmar.  Production  rules  in  the  grammar  have 
the  following  form: 

<left-non-terminal>  ::=  terminal-string  <right-non-terminal> 

Terminal  symbols  in  the  TG  production  rules  represent  protocol  actions,  and  non-terminal 
symbols  are  equivalent  to  the  states  in  the  FSA  model.  The  meaning  of  a  production  rule 
is  that  the  entity  in  the  state  specified  by  the  left-hand  non-terminal  may  take  the  action 
specified  by  the  terminal  string  and  enter  the  state  specified  by  .le  right-hand  non-tenmnal. 
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Tenninal  actions  in  the  TG  model  are  the  Mowing:  D  (Deqnene),  Q  (enQueue),  F  (Fetch), 
P  (Pnsh),  0  (pOp),  C  (Clear),  N  (Non-empty),  or  U  (fUU).  Interested  readers  shonld  refer  to 
116]  for  details.  These  actions  not  only  enable  modeling  of  a  commnnication  medinm  as  FIFO, 
non-FIFO,  and  priority  queues,  but  also  make  status  checking  of  an  output  queue  avail 
Consequently,  they  provide  a  model  more  powerful  than  the  FSA  modd,  wMe  keeping  the 
model  still  feasible  for  automatic  verification.  As  an  example,  a  TG  speafication 
is  shown  as  follows: 


Sender  Entity 


<1> 

IN 

<2>, 

<2> 

Q.2.D0 

<3>, 

<3> 

: :=  D.l.AO 

<4>, 

D.l.Al 

<2>, 

<4> 

IN 

<5>, 

<5> 

:;=  Q.2.D1 

<6>, 

<6> 

; :=  D.l.Al 

<1>. 

D.l.AO 

<5>, 

Receiver  Entity 

_ 

<1>  : :=  D.2.D0 

<2>, 

D.2.D1 

<6> , 

<2>  : OUT 

<3>, 

<3>  Q.l.AO 

<4>, 

<4>  : :=  D.2.D1 

<5>, 

D.2.D0 

<3>, 

<5>  : :=  OUT 

<6>, 

<6>  : :*  Q.l.Al 

<1>, 
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Note  that  in  the  example,  queue  2  (1)  is  the  FIFO  queue  of  the  channel  from  the  sender 
(receiver)  entity  to  the  receiver  (sender)  entity.  For  example,  Q. 2. DO  is  the  action  of  putting 
data  frame  DO  into  the  head  of  queue  2  (from  sender  entity  to  receiver  entity);  likewise, 
D.l.AO  is  the  action  of  dequeuing  the  head  message  from  queue  1  (from  receiver  entity  to 
sender  entity)  and  examining  if  the  message  is  acknowledgment  AO. 

The  TG  model  has  been  automated  [17]  and  used  to  validate  the  X.21  and  the  call  setup 
procedure  of  the  TCP  [18,  19,  20].  It  has  also  been  extended  to  handle  timing  constraints 
(caUed  the  TTG  model  [17]). 

2.3  Petri-Nets 


Petri  Nets  belong  to  the  class  of  state  transition  models,  but  have  a  theoretical  and  practical 
applicability  broader  than  that  of  finite  state  machines.  Diaz  [21]  made  an  extensive  survey  on 
how  Petri  nets  are  used  to  specify  and  analyze  protocols.  In  the  Petri  nets  model,  a  protocol  is 
modeled  by  a  number  of  component  nets  representing  different  protocol  entities.  Basically,  a 
Petri  net  is  a  graph  containing  a  set  of  places  (represented  by  circles)  and  a  set  of  transitions 
(represented  by  bars).  Directed  arcs  are  used  to  connect  places  to  transitions,  and  transitions 
to  places.  A  number  of  token  distributed  in  the  places  represent  a  marking  of  the  net  and 
also  decide  which  transitions  are  firable.  The  firing  of  a  transition  causes  a  redistribution  of 
tokens,  and  thus  moves  the  net  to  a  new  marking.  Therefore,  places  and  transitions  of  a  Petri 
net  specify  conditions  and  events,  respectively.  How  places  and  transitions  are  connected  can 
be  used  to  describe  the  behavior  of  a  protocol. 

Formally,  a  protocol  P  in  the  Petri  nets  model  is  defined  as  a  quadruple  (P,  T, £r,rno), 
where 

1,  P  is  a  finite  nonempty  set  of  places. 

2.  T  is  a  finite  nonempty  set  of  transitions. 
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Figure  2:  ABP  in  Petri  Nets  Models 

3.  E  is  a  set  of  directed  arcs,  E  C  P  x  T  U  T  x  P,  such  that  for  each  t  €  T, 

(P<,t)  eEK  {t,Pi)  eE^  (Pi,  Pi  €  P). 

4.  mo  is  an  initial  marking  function  that  assigns  a  nonnegative  integer  number  of  tokens 
to  each  place  of  the  net. 

A  transition  is  defined  to  be  firable  by  a  marking  m  iff  every  input  place  of  this  transition 
contains  at  least  one  token.  When  a  transition  is  fired,  a  token  is  removed  from  each  of  its 
input  places  and  a  token  is  added  to  each  of  its  output  places.  This  leads  the  net  to  a  new 
marking.  Fig.  2  shows  how  the  ABP  is  specified  in  the  Petri  nets  model. 


P<=lri  „rt„  have  bean  used  to  specify  and  verity  ABP  [22,  23]  and  the  call-setup  procedure 
of  a  packet -awitched  network  pd],  and  the  ISO  Transport  protocol  pS].  A  variation  of  the 
Petri  net  m„del,  called  SARA,  has  been  used  to  model  the  X.21  p6]  and  the  X.25 
In  [281,  tinting  constraints  are  added  to  Petri  nets  (called  timed  Petri  nets).  With  tinung 
information  available  in  Petri  nets,  Petri  nets  have  also  been  used  to  evaluate  the  perfor 
of  the  systen,  they  modeled  p9,  30).  Using  a  class  of  performance  Petri  nets  (PPN),  calle 
deterministic  and  stochastic  Petri  nets  (DSPN)  pO),  Bosch  and  Schmid  pi]  showed  how  t  e 
detailed  understanding  of  the  functionaUty  of  protocol  mechanisms  can  be  obtained. 


3.1  Abstract  Programs 

The  use  of  programming  languages  for  specifying  communication  protocols  is  motivated  by  the 
obserr-ation  that  protocols  are  simply  one  kind  of  algorithm,  and  that  programming  1  g  g 
provide  a  clear  and  concise  way  of  describing  algorithms.  In  an  abstract  program  model, 
protocols  are  described  as  pardlel  programs.  The  example  of  using  an  abstract  program  to 

specify  AbV  is  shown  as  follow: 


start : 


send: 


Sender  ♦♦>^*^****/ 

/♦  initialization  */ 


:=  1 


C'sata.SEHT  :=  IHDATAfPT] 
PT  +  1 

:=  (SEQ  +  1)  MOD  2 


ACX  : «  none 
♦  ♦adCDATA.SENT) 
^it(ACK) 


/♦  get  next  message  to  be  sent  ♦/ 

/*  prepare  PT  for  next  message  ♦/ 

/*  snitch  seq  #  for  the  next  message  */ 

/♦  erase  previous  ack  ♦/ 

/♦  send  message  ♦/ 

/•  wait  for  acknowledgement  */ 
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if  (ACK  ==  SEQ)  then 


/*  next  message  ♦/ 

/*  re-transmission  */ 


goto  steort 
else  goto  send 

/Diiti*****  receiver  ♦*♦***♦**/ 

/*  initialization  ♦/ 

/♦  erase  previous  sequence  #  */ 

/♦  wait  for  a  message  */ 

I*  send  Hack  ’•>/ 

/♦  output  data  received  */ 

PSEQ#  :=  (PSEQ#  +  1)  MOD  1 
end 

nack: 

send(PSEQ#) 

goto  start  /♦  message  ♦/ 

Bochmann  [32]  made  one  of  the  earUest  attempts  at  specifying  and  verifying  a  simple 
HDLC  protocol  using  an  abstract  program.  The  protocol  was  specified  in  a  free-style  Pascal. 
The  program  structure  is  event  driven  and  similar  to  a  state-transition  model  in  many  ways. 
He  partially  verified  the  protocol  by  stating  three  safety  invariants  that  described  the  number 
of  messages  sent  and  received  by  each  protocol  entity.  However,  the  proof  was  not  formal. 

Stenning  [33]  also  used  an  abstract  program  to  specify  and  verify  a  data-transfer  protocol. 
His  code  was  very  close  to  standard  Pascal,  which  enabled  him  to  rely  on  the  standard  Pascal 
rules  for  deriving  pre-  and  post-conditions  of  the  invariant  assertions. 

Krogdahl  [34]  developed  the  technique  of  vroiocol  skeletons  for  specifying  and  verifying 
safety  properties  of  classes  of  protocols.  He  attempted  to  provide  as  general  a  program  spec- 


PSEq#  :=  1 

start : 

SEQ#  :=  none 
waitCDATA.RCV,  SEQ#) 
if  (SEQ#  ==  PSEQ#) 

then  goto  nack 
else  begin 

OUTPUT (DATA.RCV) 
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ification  as  possible,  using  an  Algol-like  language.  Ansart  et  al.  [35]  developed  a  protocol 
description  and  implementation  language  (PDIL)  for  specifying  protocols  and  allowing  auto 
matic  implementation.  Based  on  standard  Pascal,  PDIL  reUeves  the  user  of  all  the  constraints 
of  putting  into  a  programming  language  form  (e.g.,  the  definition  of  data  structures  and  pro¬ 
cedures  for  manipulating  typed  objects).  The  latter  work  is  done  by  a  processor  for  PDIL, 
which  generates  coherent  Pascal  text.  Castanet  et  al.  [36]  presented  a  methodology  of  using 
Ada  for  the  specification  and  implementation  of  protocols.  Compared  with  other  program¬ 
ming  languages,  Ada  has  the  advantage  of  homogeneity.  However,  its  main  drawback  is  in 

performance. 


3.2  CSP 


Hoare’s  Communicating  Sequential  Processes  (CSP)  [37]  is  a  high-level  concurrent  language 
designed  for  distributed  systems.  A  CSP  program  consists  of  a  number  of  processes  that  do 
not  share  any  common  memory.  Communications  between  processes  are  accomplished  only 
through  message  passing.  In  CSP,  guarded  commands  are  used  to  describe  nondeterministic 
behavior  of  each  process.  Major  CSP  constructs  are  described  briefly  as  foUows: 

1.  Parallel  commands  [P1IIP2II  •  •  •  jl^n]  specify  the  concurrent  execution  of  n  processes 

2.  Input  command  P,?(x)  and  output  command  PM  specify  the  communication  between 
processes  and  Pj.  (Process  P,  sends  the  value  of  e  to  variable  ®  of  process  Pi.) 

3.  Both  alternative  command 


6i;//0i  — ►  commandlisti  | 
62; //O2  —*  commandlisti  ( 
6„;//0„  commandlistn  j 

] 
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and  repetitive  command 


♦  [ 

6i;//0i  — >  commandlisti 
W’il  1^2  ^  com7nandli3t2 
commandlistn 

] 

are  in  the  form  of  guarded  commands. 


A  protocol  in  this  model  is  represented  by  a  CSP  program,  in  which  each  protocol  entity  is 
represented  by  a  process.  As  an  example,  a  CSP  specification  of  the  ABP  is  shown  in  Figure 
3. 


3.3  CCS 

Besides  CSP,  another  abstract  program  model  that  has  been  receiving  considerable  attention 
in  the  literature  is  Milner’s  Calculus  of  Communicating  Systems  (CCS)  [38].  CCS  has  a  small 
but  powerful  set  of  operators  for  specifying  the  communication  behavior  of  concurrent  systems. 
In  this  model,  a  protocol  is  represented  by  a  set  of  communicating  agents.  An  agent  is  capable 
of  communicating  with  other  agents  (via  internal  ports)  or  with  an  external  observer  of  the 
system  (via  external  ports).  The  basic  notion  in  CCS  is  a  set  of  atomic  events  denoting  either 
internal  events  or  communication  events.  These  atomic  events  are  represented  as  follows: 

1.  as  for  input  event,  where  ®  is  a  value  variable. 

2.  ae  for  output  event,  where  a  is  a  label  complementary  to  a,  and  e  is  a  value  expression. 

3.  r  for  internal  event. 

Based  on  the  occurrences  of  events,  CCS  has  operators  to  express  the  following: 

1.  Sequences  of  events,  by  operator 
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ABP: : [Sender ll Receiver] 


Sender: : 
frame : record 

data: . . . ; 
seq: (0,1) 
end; 

DATA : . . . ; 

SEQ: (0,1); 

Ack: (0,1) ; 
done  .'boolean; 

SEQ:=1; 

* [User? (DATA)  — >  SEQ  :=(SEQ+1)  mod  2; 

frame . dat  a : »D ATA ; 
frame . seq : =SEQ ; 
done:»false; 

♦ [-done ; Receiver ! (frame) — >Receiver? (Ack) ; 

[Ack*SEQ  — >  done:*true;  I 
Ack~'  SQ"*-!)  mod  2  — >  skip; 

] 


Receiver: : 

frame :/*same  as  in  Sender*/ 
exp: (0,1) ; 

exp:^!; 

*  [Sender? (frame) — >  [frame. seq- (exp+l)mod  2  — >  User2!  (frame. data)  ; 

exp:“(exp'H)mod  2  | 

frame .  seq=exp — >skip 

]; 

Medium! (exp) 


Figure  3:  ABP  Specified  in  CSP 
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Sender: 

S  <=  I. So 

So  <=  ao.{So‘I ’Si  +  5i.5o} 

4=  ai.{5i./.5'o  +  ^o-‘S'i} 

Receiver:  _  _ 

Rq  •<=  ao.O.^O'-^i  oci’Si.Rq 

Ri  <=  ai.O.^i.jRo  +  oq.So-Ri 

Figure  4:  CCS  Model  of  the  ABP 

2.  Choice  between  sequences  of  events,  by  operator 

3.  Recursion  for  specifying  infinite  sequences,  by  operator 

4.  Parallel  composition  of  agents  to  form  systems  of  communicating  agents,  by  operator 

”11”. 

5.  Hiding  of  a  subset  of  the  internal  ports,  enabling  one  to  abstract  away  from  the  internal 
details  of  an  agent,  by  operator 

Formally,  a  protocol  in  CCS  is  defined  by  the  following  BNF  notation: 

t  ::=  X  I  op(ti,  t2,  ’  ■  * }  tn)  I  ®  4=  t 

where  i  is  a  variable  name,  op  is  an  operator,  and  (tijtj,  •  •  •  ,tn)  is  a  CCS  expression.  As  an 
example,  a  CCS  specification  of  the  ABP  is  shown  in  Figure  4.  Note  that  in  this  example, 
a  represents  data  flowing  from  Sender  to  Receiver,  and  S  represents  acknowledgment  flowing 
from  Receiver  to  Sender,  and  I  and  0  are  communication  actions  with  outside  observers. 

The  global  behavior  of  a  protocol  in  the  CCS  model  can  be  computed  by  applying  the 
operation  of  parallel  composition  to  all  its  communicating  agents.  For  example,  the  ABP  can 
be  composed  as  follows:  (S  ||  Rq).  During  parallel  composition,  pairs  of  events  such  as  ax 
and  ae  can  be  coupled  and  become  a  rendezvous  event  x  :=  e. 

One  of  the  formal  specification  languages  developed  by  ISO,  called  LOTOS,  is  heavily 
based  on  CCS.  LOTOS  will  be  discussed  in  Section  4.4. 
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3.4  Other  Programming  Language  Models 

Other  programming  language  models  to  be  described  in  the  rest  of  this  section  include  temporal 
logic  techniques  and  abstract  data  types. 

Temporal  logic  was  first  introduced  by  Pnueli  [39]  as  an  adaptation  of  a  classical  model  logic 
suitable  for  defining  the  semantics  of  computer  programs.  Later,  it  was  used  by  Hailpern  and 
Owicki  [40]  and  Schwartz  and  Melliar-Smith  [41]  to  specify  and  verify  the  liveness  (or  progress) 
property  of  protocols.  The  Uveness  property  requires  that  certain  transitions  eventually  take 
place,  and  is  difficult  or  impossible  to  state  and  prove  in  state-transition  specifications,  since 
conventional  logic  cannot  refer  to  any  state  other  than  the  present  one. 

Hailpern  and  Owicki  [40]  modeled  a  protocol  system  as  a  set  of  interacting  modules  that 
represent  the  logical  units  of  the  system.  Both  active  (called  process)  and  passive  (called 
monitor)  modules  may  be  specified.  They  exploit  this  modularity  in  their  specifications  and 
proofs.  They  have  verified  the  safety  and  Uveness  properties  of  the  ABP,  and  Stenning’s 

data-transfer  protocol  [42]. 

Schwartz  and  MeUiar-Smith  [41]  developed  specifications  employing  temporal  logic  with 
a  more  expUcit  notion  of  system  state.  They  divided  the  task  of  specifying  and  verifying 
protocols  into  two  parts:  service  level  specification  and  network  level  specification.  The  service 
level  defines  the  operations  avaUable  to  the  users  of  the  protocol,  while  the  network  level 
represents  an  abstract  specification  of  the  essential  details  of  the  protocol  implementation. 
The  goal  is  to  verify  the  service  level  from  the  network  level  and  to  verify  the  network  level 
from  the  protocol  code.  They  illustrated  the  feasibiUty  of  their  technique  by  formally  verifying 
both  safety  and  Uveness  properties  of  the  ABP. 

In  1984,  Sabnani  and  Schwartz  [43]  verified  a  multidestination  protocol,  caUed  the  selective 
repeat  procedure,  for  a  satelUte  broadcast  channel  using  a  time-division  multiplexed  technique. 
This  procedure  is  modeled  as  a  parallel  program  in  a  Pascal-Uke  language.  The  correctness 
of  the  parallel  program  model  is  shown  using  temporal  logic.  Both  the  safety  and  Uveness 
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properties  are  satisfied. 

Another  programming  language  model  is  abstract  data  types  [44].  Abstract  data  types 
are  an  attempt  to  encapsulate  data  and  the  operations  that  manipulate  it.  There  are  two 
approaches  in  this  area:  abstract  model  and  axiomatic.  However,  the  distinction  between 
these  two  approaches  may  not  be  so  great  in  practice,  since  it  is  possible  to  write  abstract 
model  specifications  in  the  axiomatic  notation.  It  was  reported  by  Sunshine  [45,  46]  that 
experience  with  these  techniques  is  stiU  limited.  More  research  in  this  direction  is  required. 

3.5  Comparison  to  State  Transition  Model 

The  major  advantage  of  programming  language  models  over  state  transition  models  is  their 
capability  to  handle  variables  and  parameters,  such  as  sequence  numbers  and  timers,  which 
may  take  on  values  of  a  wide  range.  Another  advantage  is  their  ability  to  specify  a  whole 
protocol  and  most  of  its  properties  rather  than  only  general  correctness  properties. 

However,  since  protocol  specification  in  programming  language  models  may  be  very  similar 
to  protocol  implementations,  unessential  features  are  often  combined  with  the  essential  algo¬ 
rithms.  In  addition,  efforts  to  prove  the  correctness  of  programs  representing  communication 
protocols  far  exceed  those  required  to  develop  algorithms  or  programs.  Program  proof  usually 
depends  heavily  on  human  ingenuity  and  intuition,  and  the  automation  of  proof  seems  quite 
impossible  and,  therefore,  is  still  fax  away  from  being  of  significant  use. 

4  Hybrid  Models 

4.1  EFSM 

The  extended  finite  state  machine  (EFSM)  model  is  a  generalization  of  the  FSA  model.  The 
EFSM  model  allows  multiple-state  variables  of  various  types;  consequently,  a  state  in  this 
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model  becomes  e  vecloi  of  these  variables  and  the  transition  fnnction  becomes  more  compiea. 
The  values  of  these  state  variables  are  chanjed  by  the  occurrence  of  events.  An  event  can 
occur  only  if  certain  enabUng  condiUons  are  satisfied.  An  enabling  condition  is  a  predicate  on 


(s^seqoseq] 
rasg:  =buf  (s_se<j)  ; 

<<SeXiaOr>>  imsgts.seq) 

s  seq:=ls_seq+l)»od(WS+l) 


&&  R_ack<>  ( ack+ (WS+ 1 )  1 

s_seq: * (ack+l)rood (WS+1 ) 


msg(8eq} . 

( seq+ 1 )  linod  ( WS+ 1 ) 


&&  R_ack*=  ( ack-*- 1 )  ®od  ( WS+ 1 ) 


&&  R_ack==seql 


[?R_ack  && 

R_ack-= (ack+l)®od{WS+l) 
actt;=R_ackiw  it  R_aclc<s_se<a 


<<Roceiver» 


[  Tsasg  (r__se<j)  r^seqoseql 

R_ack;  =  (Beq+WS)®od(WS'»-l)  ; 

li_ack 


R_ack:=seq; 

S0q :  =  ( seq+1 ) ntcd  (WS+1 )  ; 
I R_ack 


(?Mag(r_req)  &&  r_seq==seqj 
OUT{msg) 


Figure  5:  ABP  in  the  EFSM  Model 

the  state  variables.  When  more  than  one  event  in  an  event-driven  system  are  enabled,  any 
one  of  the  enabled  events  is  allowed  to  occur,  resulting  in  nondeterminism. 

As  in  the  FSA  model,  in  the  EFSM  model,  each  protocol  is  represented  by  a  set  of  com¬ 
municating  protocol  entities.  The  communication  is  done  by  message  passing  through  com¬ 
munication  Aanuel  between  protocol  entities.  Formally,  a  protocol  entity  is  defined  as  Mows 


An  EFSM  Protocol  Entity  P.  is  an  eight-tuple  («,  W,  Vul,  S,  A,  S,  s,  /),  where: 


1.  q  is  the  set  of  states  in  P,. 


-51 


2.  W^is  the  finite  set  of  variables  used  in  P,.  The  values  of  the  variables  in  W 
may  change  only  as  the  result  of  the  execution  of  some  transitions  and/or 
time  change. 

3.  Viz/ is  an  n-tuple,  where  n  is  the  number  of  variables  in  W  and  Val  represents 
the  initial  values  of  the  variables  in  W. 

4.  £  is  the  finite  set  of  service  transitions  in  P». 

5.  A  is  the  finite  set  of  peer  transitions  in  P*.  Note  that  a  (peer  or  service) 
transition  in  P,  consists  of  two  parts:  Predicate  and  Action.  A  predicate  is  a 
combination  of  some  mathematic  operations  on  the  variables  in  Wand  repre¬ 
sents  the  required  conditions  that  the  entity  has  to  be  in  for  the  corresponding 
action  part  of  the  transition  to  be  executable. 

6.  S  is  the  transition  function  of  P,  which  maps  g  x(SU  A)  into  g;  if  =  S2, 

where  si  €  q,  S2  €  g,  and  t  €  (S  U  A),  si  is  called  the  starting  state  of  t  and 
52  is  the  ending  state  of  t.  Note  that  a  transition  U  is  said  to  be  executable 
only  when  the  current  state  of  Px  is  the  starting  state  of  U  and  the  predicate 
condition  is  fully  met.  In  addition  to  the  aforementioned  conditions,  for  a 
receive/read  transition  ^  to  be  executable,  the  message  to  be  received/read 
must  be  already  in  the  incoming  channel  to  Px. 

7.  t  is  the  initial  state  of  P». 

8.  /  is  the  set  of  the  final  states  in  P,.  Note  that  for  a  typical  non-terminating 
protocol,  /  usually  has  only  one  element,  t,  which  is  the  initial  state  of  the 
entity. 

Note  that  in  this  definition,  a  distinction  is  made  between  two  kinds  of  transitions  executed  m 
the  entities,  namely.  Peer  Transitions  that  support  the  interaction  between  two  peer  protocol 
entities  and  5cmce  Transitions  that  perform  the  interaction  between  a  protocol  entity  and 
its  environment  (e.g.  the  protocol  service  users)  through  the  SAP  (service  access  point). 

An  example  that  shows  how  to  apply  EFSM  to  specify  the  ABP  is  given  in  Fig:  5.  In  this 
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example,  a  predicate  is  enclosed  in  a  pair  of  square  brackets.  In  both  predicate  and  action 
parts  of  a  transition,  ”!”  and  ate  used  to  denote  sending  of  a  message  or  acknowledgement 
and  reception  of  a  message  or  acknowledgement,  respectively. 

Several  researchers  have  proposed  particular  forms  of  such  EFSM  models  for  spemfymg 
protocols.  While  differing  in  names  and  in  the  detaUs  of  syntax,  they  may  be  considered 

equivalent  in  expressive  power. 

Based  on  KeUer’s  transition  model  for  parallel  programs  [48],  Bochmann  has  proposed 
a  general  transition  modd  for  the  formal  spediication  of  protocols,  the  spedficat.on  of  the 
services  provided,  and  the  verification  of  the  correct  operations  (49].  He  discnssed  these  issues 
by  considering,  as  an  example,  the  HDLC  classes  of  procedures. 

In  1989,  Chn  [SO)  extended  the  TG  modd,  called  the  extended  transmission  grammar 
(ETG)  modd,  to  contain  context  variables  such  as  sequence  numhers  in  protocol  specifications. 
The  notion  of  communicating  sequential  processes  (CSP)  (37]  in  using  ”?”  and  !  as  the 
receive  and  send  events,  respectively,  is  used.  In  this  context,  ”?”  is  a  blocking  receive  as  it  is 
in  CSP;  whereas  ”!”  is  a  non-blocking  send  that  wiU  not  wait  for  the  communicating  partner 
to  he  ready  for  the  sei  i  event  to  he  executable,  as  is  teqmred  for  ”!”  in  CSP. 

Shankar  and  Lam  pi]  used  an  event-driven  process  model  to  specify  a  version  of  the 
HDLC  protocol  between  two  communicating  protocol  entities.  The  protocol  is  verified  using 
the  method  of  projections  152].  The  verification  selves  as  a  rigorous  exerdse  to  demonstrate 
the  applicability  of  this  method  to  the  analysis  of  realistic  protocols.  This  procedure  has  been 

automated. 


4.2  SDL 

The  Specification  and  Description  Language  (SDL)  [53,  54]  was  developed  hy  study  groups 
SGXI  and  SGX  of  the  CCITT.  It  is  meant  spedfically  for  the  specification  and  design  of  the 
telecommunications  systems,  such  as  tdephone  switches.  The  study  was  started  in  1968.  Since 
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c^c  Statel  j) 


Start 


state 


EI> 

input 


output  decision 


Figure  6:  Basic  Constructs  of  SDL 


then,  it  has  evoW  from  an  infomial  drawing  technique  to  a  formal  description  technique. 
There  are  two  variants  of  SDL  in  use:  a  graphical  form  which  is  more  popular,  and  a  textual 

form. 


SDL  provides  the  concept  of  system  as  a  boundary  between  the  specification  and  the 
environment.  The  behavior  of  a  system  is  constituted  by  the  combined  behavior  of  a  number  of 
processes  in  the  system.  The  cooperation  between  the  processes  is  performed  asynchrononsly 
by  discrete  messages,  caUed  signal.  The  concept  of  block  is  provided  as  a  way  to  structure  a 
system.  One  or  more  processes  are  grouped  into  a  block.  From  a  modeUng  point  of  view,  a 
system  is  made  up  of  blocks  that  interconnect  with  each  other  and  with  the  environment  by 
channels.  A  channel  is  a  means  of  conveying  signals. 

In  SDL,  a  process  is  an  EFSM.  There  are  five  basic  constructs  for  the  description  of  a 
process:  start,  state,  input,  output  and  decision  as  shown  in  Figure  6.  SDL  also  allows 
abstract  data  type  to  be  used  in  the  specification.  Figure  7  describes  a  version  of  ABP  in 
SDL.  In  this  specification,  the  sending  of  signal  of  type  msg  in  the  sender  matches  with  the 
corresponding  receiption  of  signal  of  type  msg.  This,  thus,  accompUshes  the  foUowing  two 
assignments:  i  :=  o  and  a  :=  seq.  It  happens  to  signal  of  type  ack,  too. 

The  most  recent  extensions  to  the  language  are  in  the  area  of  object-orientation  which 
are  included  in  SDL-92  [55].  In  SDL-92,  a  clear  distinction  between  types  and  instances, 
specialization  of  types  into  subtypes,  and  the  concept  of  generic  types  are  introduced.  This 
new  language  is  backward  compatible. 
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Figure  7:  ABP  written  in  SDL 
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4.3  Estelle 


Estelle  [56]  is  an  FDT  standardized  by  ISO.  It  can  be  used  to  describe  distributed  concur¬ 
rent  information  processing  systems.  The  language  is  based  on  the  concept  of  EFSM.  A 
distributed  system  specified  in  Estelle  is  viewed  as  a  collection  of  communicating  components 
called  tasks.  Tasks  are  instances  of  modules.  Modules  may  be  nested  and  organized  in  a 
hierarchical  structure.  Each  module  has  a  number  of  input /output  access  points  called  inter¬ 
action  points.  A  task  can  send  a  message  (is  called  an  interaction)  to  another  task  through 
a  previously  established  communication  channel  between  two  interaction  points  of  the  tasks. 
The  internal  behavior  of  a  module  is  described  in  terms  of  a  nondeterministic  communicating 
state  automaton  whose  transition  actions  are  given  in  the  form  of  Pascal  statements  (with 
some  restrictions  and  extensions).  Each  transition  begins  with  the  keyword  irans.  A  tran¬ 
sition  declaration  composed  of  two  parts:  the  transition  condition  and  the  transition  action. 
The  transition  condition  is  composed  of  one  or  more  clauses  of  the  following  categories. 

from-clause:  {from  Ai,  A2,  •  •  • ,  where  Ai  is  a  state  identifier) 

when-clause  {when  p.m,  where  p  is  an  interaction  point  and  m  is  an  interaction) 

provided-clause  {provided  where  5  is  a  boolean  expression) 

priority-clause  {priority  ti,  where  n  is  a  non-negative  constant) 

delay-clause  {delay (EiM,  where  Ex  and  E^  are  non-negative  integer  expressions) 

Transitions  without  a  when-clause  are  called  spontaneous  transitions.  A  spontaneous  transi¬ 
tion  with  a  delay-clause  is  called  a  delay  transition. 

Besides  containing  a  transition  block  of  a  sequence  of  Pascal  statements  between  begin 
and  end^  a  transition  action  may  also  have  a  to-clause  to  specify  the  next  state  which  will 
be  attained  once  this  transition  is  fired.  Without  a  to-clause,  a  transition’s  next  state  is  its 
current  state. 
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The  following  is  a  spedScatlon  of  ABP  in  EsteUe.  Note  that  al  modules  are 
principal  module  called  specification  module. 

specification  ABP  systemprocess ; 

■C  This  is  the  top  level  module  body  (specification)  . 

The  specification  has  the  attribute  system  process 

and  all  its  children  (  sender,  receiver)  are  processes.  } 

default  individual  queue; 

type 

MsgType* ...; 

channel  NChannel (Sender, Receiver ) ; 

by  Sender: 

msg (M : MsgType ;  Seq : integer) ; 
by  Receiver: 

ack(Seq: integer) ; 

channel  SServ(User .Provider) ; 
by  User: 

send (M: MsgType) ; 

chemnel  RS erv (User .Provider) ; 

by  Provider: 
del (M: MsgType) ; 

{  Module  header  definitions  } 

module  SenderType  process; 


defined  in  a 
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ip  urSServ (Provider)  common  queue; 
s:NChannel( Sender)  individual  queue; 
end;  {  of  SenderType  > 

module  ReceiverType  process; 

ip  u:RServ (Provider)  common  queue; 
s:NChannel (Receiver)  individual  queue; 
end;  {  of  ReceiverType  > 

•(  The  body  of  the  Sender  } 

body  SenderBody  for  SenderType; 

type 

BufferType=. . . ; 

vax 

b  :  integer; 

Msg  :  MsgType; 

UnAckedMsgs:  BufferType; 

state  SS1,SS2; 

procedure  Store(var  BiBufferType;  var  McMsgType), 
primitive; 

procedure  Retrieve(var  B:BufferType;  i: integer;  Var  MrMsgType); 
primitive; 

{  Initialization  part  for  SenderBody  } 
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initializ* 


to  SSI  {  S  is  the  initial  state  } 
begin  b  :=  0;  end; 

■C  Transition  decleuration  peart  for  SenderBody  } 

trans 

from  SSI 
to  SS2 

when  u.send 
begin 

output  s.msg(M,b); 

Store (UnAckedNsgs ,M) ; 
end; 

from  SS2 
to  SS2 
when  n.ack 

provided  Seq  <>  b 
begin 

Retrieve (UNAckedMsgs , Msg) ; 
output  s . msg (Msg , b) ; 
end; 


to  SSI 
when  n.ack 

provided  Seq  =  b 


-58- 


begin 
b  :=  1  -  b; 
end; 

end;  {  of  SenderBody  }■ 

body  ReceiverBody  for  ReceiverType; 
{  Body  for  ReceiverType  }• 
vax 

b  :  integer; 

state  SR; 

initialize 

to  SR 

begin  b  :=  0;  end; 

trans 

from  SR 
to  SR 

vhen  n.msg 

provided  b=Seq 
begin 

output  u . del (H) ; 
output  s . aclc(Seq)  ; 
b  :=  1  -  b; 
end; 
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to  SR 


whan  n.msg 

provided  bOSeq 

begin  output  s.ack(Seq);  end; 
end;  {  of  ReceiverBody  } 

{  Declare  IPs  for  the  specification  (the  outermost  module) .  } 
modvau: 

{  Modvaurs  are  the  realization  of  modules.  This  declaration 
declzures  how  each  modv€Lr  "looks  like,"  i.e.,  to  define  its 
type.  The  content  of  each  module  is  associated  with  the 
module  bodies  by  the  "init"  statements  below  } 

SendEntity : SenderType ; 

RecEnt ity ; ReceiverType ; 

initialize 

begin 

{  Associates  modvars  to  their  body  } 
init  SendEntity  with  SenderBody; 
init  RecEnt ity  with  ReceiverBody; 

{  Connecting  and  attaching  channels  } 
connect  SendEntity. s  to  RecEntity.s; 

end; 


end.  -{Specif ication} 


There  are  a  lot  of  works  in  developing  toolsets  for  designing  protocols  using  Estelle.  For 
instance,  Estelle  Development  Toolset  (EDT)  [57]  provides  tools  for  compiling  and  simulating 
Estelle  protocols  specifications,  and  Estelle  Simulator  based  on  an  Interpretative  Machine 
(ESTIM)  [58]  is  a  tool  for  validating  protocols.  Recently,  some  visualization  tools  are  also 
being  developed  for  the  Estelle.  A  tool  called  GROPE  [59]  can  provide  a  dynamic,  graphical 
representation  of  a  simulated  Estelle  specification.  GROPE  animates  the  firing  of  Estelle 
transitions  and  exchange  of  interactions  over  channels. 


4.4  LOTOS 


The  Language  of  Temporal  Ordering  Specification  (LOTOS)  [60,  61]  was  adopted  as  ISO 
international  standard  IS8807  in  1989.  The  basic  idea  from  which  LOTOS  was  developed 
is  that  systems  can  be  specified  by  defining  temporal  relation  among  the  interactions  that 
constitute  the  externally  observable  behavior  of  a  system.  Contrary  to  what  its  name  seems 
to  suggest,  LOTOS  is  not  related  to  temporal  logic,  but  it  is  based  on  process  algebraic 
methods.  CSP  and  CCS  are  also  methods  of  process  algebra. 

A  LOTOS  specification  describes  a  system  via  a  hierarchy  of  process  definitions.  A  process 
is  an  entity  able  to  perform  internal  actions  and  to  interact  with  other  processes  via  interaction 
points  called  gates.  Complex  interactions  between  processes  are  built  up  from  elementary  units 
of  synchronization  which  is  called  an  event.  The  constructs  of  LOTOS  are  similar  to  those  of 
CSP  and  CCS.  LOTOS  has  the  following  major  constructs: 

Inaction:  stop 

A  completely  inactive  process. 

Action  Prefix:  g;B 

This  is  a  unary  prefix  operator  which  produces  a  new  behavior  expression  out  of  an 
existing  one,  by  prefixing  the  latter  with  an  action  followed  by  a  semicolon. 

Choice:  Bi  []  B^ 
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It  denotes  a  process  that  behaves  either  like  Bi  oi  B2. 

Parallelism:  B^  \  [91,92,- \  B2 

The  set  ^={91,92,  - "  ,gn}  is  a  set  of  synchronization  gates.  This  implies  that  when 
process  Bi  is  ready  to  execute  some  actions  at  one  of  the  synchronization  gates,  it  is 
forced,  in  the  absence  of  alternative  actions,  t  ;  wait  until  B2  offers  the  same  action.  In 
the  case  that  the  set  of  synchronization  gates  is  empty,  the  construct  is  pure  interleaving. 
On  the  other  hand,  when  the  set  is  aU  the  gate,  it  is  full  synchronization. 

Hiding:  Hiding  allows  one  to  transform  some  oberservable  actions  of  a  process  into  unob¬ 
servable  ones. 

A  version  of  LOTOS  specification  for  ABP  is  shown  in  Figure  8. 

The  major  advantage  of  LOTOS  in  comparing  to  other  two  standard  FDT,  SDL  and  Es¬ 
telle,  is  that  it  can  allow  designer  to  reason  formally  about  behavior  since  the  algebras  that  it 
is  based  define  a  rigorous  set  of  transformation  rules  and  equivalence  relations.  However,  this 
benefit  also  has  its  short  fall  since  its  mathematical  nature  makes  it  harder  to  use  than  the 
other  two.  In  the  past  few  years,  collaborated  affords  from  ISO  and  CCITT  have  been  made 
to  extend  LOTOS  with  graphical  syntax.  G-LOTOS  which  is  currently  being  standardized 
is  intended  to  provide  a  better  readability  zmd  more  intuitive  understanding  of  formal  speci¬ 
fications  than  textual  LOTOS.  G-LOTOS  has  the  same  semantic  as  the  textual  LOTOS;  an 
introduction  to  G-LOTOS  can  be  found  in  [62]. 


4.5  Others  Hybrid  Models 

There  are  other  hybrid  models  that  were  proposed  for  protocol  specification.  The  language 
IBM  uses  for  describing  SNA  is  called  format  and  protocol  language  (FAPL).  It  is  derived 
from  PL/1  and  contains  additional  constructs  for  handling  FSMs  and  processes.  A  protocol 
specified  in  this  form  is  precise,  readily  accessible  to  the  implementing  product  designers  and 
programmers,  and  structurally  close  to  the  implementations  [63,  64,  65]. 


specification  M_ABP[in,out]  := 
hide  S_Chan  in 

Sender [in, S.Chan] (0)  I  [S.Chan]  | 
Receiver [SL.Chan, out] (0) 


where 

process  Sender[in,S_Chan] (seq_cnt) := 

in  ?  MsgiMsgType  — >  Transmit  [S_Chan]  (Msg, seq_cnt) 

where 

process  Transmit [S.Chan] (Msg,seq_cnt) := 

S.Chan  !  Msg  !  seq.cnt; 

S_Chan  ?  Seq: integer  — > 

(  (Seq  ==  seq.cnt)  — > 

Sender [in, S.Chan]  (1  -  seq.cnt) 
[]  (Seq  !=  seq.cnt)  — > 

S.Chan  !  Msg  !  seq.cnt; 
Transmit  [S.Chan]  (Msg ,  seq.cnt) 

) 

endproc 

endproc 


process  Receiver [S.Chan, out] (rec.cnt) 

S.Chan  ?  Msg:MsgType  ?  Seq: integer  — > 

(  (Seq  ==  rec.cnt)  — > 
out!  Msg; 

S.Chan  !  rec.cnt; 

Receiver [S.Chan, out] (1-rec.cnt) ; 

[]  (Seq  1=  rec.cnt)  — > 

R.Chan  !  (1-rec.cnt); 

Receiver [R.Chan, out] (rec.cnt ,Wsize) 


endproc 

endspec 


Figure  8:  ABP  Specified  in  LOTOS 
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Aggarwal  et  al.[66]  has  proposed  the  selection/resolution  model  for  specifying,  analyzing 
and  validating  the  behavior  of  protocols.  The  model  centers  around  abstract  entities  called 
processes.  Parallelism  is  addressed  directly  with  concurrent  transitions  in  each  process  depen¬ 
dent  on  the  status  of  neighboring  process.  Protocol  specification  is  accomplished  by  defimng 
many  small  and  easy  to  specify  interacting  processes,  which  collectively  describe  the  behavior 
of  the  protocol.  The  feasibility  of  the  model  was  demonstrated  by  applying  it  to  the  ABP  and 
a  file-transfer  protocol  [67]. 

Krumm  and  Drobnik  [68,  69]  proposed  the  CIL  (Communication  Service  Implementation 
Language)  approach  for  the  development  of  communication  services.  It  is  based  on  an  event- 
oriented  model  of  program  execution  and  a  first-order  predicate  calculus.  The  verification  of 
a  program  written  in  CIL  is  supported  by  the  automated  generation  of  program  axioms  and 
by  the  predicate  calculus. 

Meer  et  al.  [70]  introduced  algebraic  specification  methods  based  on  language  ACT  ONE 
[71].  The  algebraic  methods  model  abstract  data  types  as  many  sorted  algebras.  These  sorted 
algebras  are  used  as  mathematical  objects  and  serve  as  a  semantic  domain  of  the  system  being 
modeled.  One  advantage  of  this  approach  is  that  the  mathematical  objects  provide  a  precise 
semantics  to  its  specification. 


5  Conclusion 

Using  FDTs  in  protocol  specification  facilitates  the  development  of  unambiguous,  complete 
and  correct  protocol  specifications.  It  also  forms  the  basis  for  automated  protocol  verification, 
semi-automated  implementation  of  protocols  and  automatic  generation  of  test  sequences  for 
the  conformance  testing  of  a  protocol  implementation  against  its  standard. 

Various  FDTs  and  their  models  have  been  described  in  this  paper.  Among  them,  FSA 
is  one  of  the  earliest  models  and  has  been  used  extensively  in  areas  such  as  formal  protocol 
verification,  conformance  testing,  etc.  However,  due  to  FSA’s  severe  restrictions  as  discussed 
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in  Section  2.1,  researchers  have  been  searching  for  better  models.  For  example,  efforts  within 
ISO  and  CCITT  have  been  made  since  the  late  70s  to  develop  standardized  FDTs.  For  these 
efforts,  hybrid  models  have  received  the  most  attention.  In  fact,  after  approximately  more  than 
a  decade  of  hard  work,  three  complementary  standardized  FDTs  prevail  in  their  full  status 
of  international  standards  (IS)  or  recommendation:  Estelle  (IS9074)  and  LOTOS  (IS8807) 
defined  by  ISO,  and  SDL  (ZlOO)  by  CCITT.  These  FDTs  have  the  full  expressive  power  and 
abstraction  capabiHties  to  allow  for  the  complete  architectural  specification  of  OSI  protocols 
and  services  as  well  as  the  specification  of  OSI  architecture  concepts  and  constructions  at 
appropriate  levels  of  abstraction. 

Since  the  standardization  of  these  FDTs,  enhancements  and  many  supporting  tools  that 
facilitate  the  use  of  them  in  protocol  specification  have  been  developed.  However,  the  research 
on  how  these  standard  FDTs  can  be  applied  to  other  areas  of  protocol  engineering  such  as 
protocol  conversion  and  synthesis  is  just  beginning.  To  gain  worldwide  acceptance,  future 
research  on  FDTs  should  focus  on  broadening  the  applications  of  these  standard  FDTs  to 
other  areas  of  protocol  engineering. 
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Abstract 

In  this  paper,  a  method  is  proposed  to  produce  test  paths 
that  check  both  data  flow  and  control  flow  for  a  protocol 
specified  in  the  Extended  Finite  State  Machine  (EFSM) 
model.  The  method  first  identifies  a  set  of  paths  from  a 
given  specification  to  cover  a  dataflow  selection  criterion, 
then  it  appends  state  check  sequences  to  some  transitions 
in  this  set  of  paths  for  checking  control  flow.  The  criterion 
that  our  method  employs  for  selecting  these  transitions  is 
called  effective  domain  for  testing.  Effective  domain  for 
testing  is  used  to  evaluate  how  effective  a  transition  can 
be  tested  in  a  given  path  in  terms  of  the  range  of  values 
that  the  variables  in  this  transition  can  have.  Since  each 
transition  can  appear  in  several  paths,  our  method  is  to 
append  state  check  sequences  to  its  occurrences  that  have 
distinct  effective  domains.  In  addition,  our  method  will 
compute  the  path  domain  for  each  path  and  make  some 
inexecutable  paths  executable. 

1  Introduction 

Confomance  testing  aims  at  demonstrating  that  a  pro¬ 
tocol  Implementetion  Under  Test  (lUT)  conforms  to  the 
specification  that  it  implements.  Since  an  lUT  is  treated 
as  a  blackbox,  test  sequences  that  are  sequences  of  in¬ 
put/output  are  needed  for  a  tester  to  infer  the  properties 
of  the  lUT.  For  the  purpose  of  generating  test  sequences, 
paths  that  are  believed  to  be  most  error  revealing  must  be 
selected  from  the  corresponding  specification.  In  the  case 
that  the  specification  is  written  in  the  Finite  State  Machine 
(FSM)  model,  the  paths  are,  indeed,  the  test  sequences. 
However,  if  the  specification  is  specified  in  the  Extended 
Finite  State  Machine  (EFSM)  model,  test  sequences  will 
need  to  be  constructed  from  these  paths  by  substituting 
appropriate  values  for  the  input  variables  of  each  path. 

•Research  reported  herein  was  supported  by  U.S.  Army  Research 
Office,  under  contracts  No.  DAAL03-9 1  -G-0093  and  No.  DAAL03-92- 
G-0I84.  The  views,  opinions,  and/or  findings  contained  in  this  paper 
are  those  of  the  authors  and  should  not  be  construed  as  an  official  De¬ 
partment  of  the  Army  position,  policy  or  decision. 


In  the  literature,  protocols  specified  in  the  FSM  are  al¬ 
ways  tested  by  making  sure  that  there  is  no  control  flow 
MTors  associated  with  each  transition.  For  such  a  pur¬ 
pose,  state  check  sequences  such  as  Unique  Input/Output 
(UIO)  [1]  and  Characterizing  set  (W-set)  [2]  are  employed 
to  identify  the  tail  state  of  a  transition.  However,  these 
techniques  are  inadequate  for  generating  paths  that  can 
effectively  test  a  protocol  specified  in  the  EFSM  since 
the  model  describes  not  only  the  control  aspect  of  the 
protocol,  but  also  the  data  aspect  of  the  protocol.  For 
testing  an  lUT  specified  in  the  EFSM,  some  methods 
[3,  4,  5]  have  also  been  proposed.  These  methods  em¬ 
ploy  the  techniques  of  dataflow  analysis  to  analyze  the 
Hata  interactions  among  the  variables  and  then  to  choose 
paths  from  the  specification  to  cover  these  interactions. 
Although  the  data  flow  of  a  protocol  can  be  effectively 
examined  by  these  methods,  the  control  flow  is  ignored 
by  these  methods.  In  addition,  these  methods  only  con¬ 
cern  with  the  issue  of  path  selection;  two  other  important 
issues,  namely  deciding  path  executability  and  identifying 
path  domains  for  each  selected  path,  are  not  addressed. 

In  this  paper,  a  method  is  proposed  to  combine  data 
flow  testing  with  control  flow  testing.  In  our  method,  a 
set  of  paths  is  first  selected  to  fulfill  certain  dataflow  se¬ 
lection  criterion,  then  state  check  sequences  are  a{^nded 
to  the  transitions  in  the  set  for  checking  control  flow  er¬ 
rors.  As  a  transition  can  appear  in  several  paths,  effective 
domain  for  testing  is  introduced  as  a  criterion  for  eval¬ 
uating  the  occurrences  of  a  transition.  The  concept  of 
effective  domains  is  employed  in  this  paper  as  a  criterion 
for  measuring  how  extensive  a  transition  can  be  tested 
in  a  given  path  in  terms  of  the  range  of  possible  values 
that  the  variables  of  this  transition  can  have  in  the  path. 
For  each  transition,  our  method  will  append  state  check 
sfquMiftve  to  its  occurrences  that  have  distinct  effective 
domains.  In  addition  to  generating  test  paths  for  testing 
both  control  flow  and  data  flow,  our  method  also  gener¬ 
ates  path  domains  for  the  respective  test  paths  and  makes 
some  inexecutable  test  paths  executable.  As  mentioned 
above,  these  two  problems  are  very  important  problems; 
however,  hardly  any  in  depth  discussions  are  provided  in 
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the  literature. 


This  paper  is  organised  as  follows:  In  S«tion  2,  a 
model  of  the  EFSM  and  the  concept  of  dataflow  testing 
are  introduced.  For  ease  of  presenting  our  approach  in 
the  subsequent  sections,  a  dataflow  criterion  cailai  all- 
du-paths  criterion  is  described  in  detail.  The  concept  of 
effective  domain  for  testing  is  discuss«i  in  Section  3. 
Then,  assuming  that  a  set  of  paths  for  covering  all-du- 
paths  criterion  is  given,  a  procedure  for  path  selectimi  is 
developed  in  Section  4.  In  Section  5,  two  relatnl  works 
recently  published  in  the  literature  are  compared  with  our 
work. 

2  Background 

2.1  Extended  Finite  State  Machine 

The  O^SM  model  extends  the  FSM  model  by  using  vari¬ 
ables  to  describe  the  data  aspect  of  a  protocol.  In  this 
paper,  a  protocol  entity  is  modeled  as  an  H^SM  that  is 
specified  by  a  state-transition  graph.  In  the  graph,  a  state 
is  represented  by  a  vertex  and  a  transition  by  a  directed 
edge.  Furthermore,  it  is  assumed  that  every  transition  in 
the  EFSM  includes  the  following  four  parts  that  will  be 
executed  in  this  order:  input,  enabling  conditions,  pro¬ 
gram  segment,  and  output 

Each  of  the  foiff  parts  can  have  zero  or  more  state¬ 
ments.  Note  that  the  order  of  statements  given  in  each 
part  must  be  obscrvwi.  The  input  and  output  parts  spec¬ 
ify  the  interaction  of  a  protocol  with  its  environment  An 
input  statement  is  prefixed  by  a  ’?’  and  an  ouq>ut  state¬ 
ment  is  prefixrf  by  a  ’!'.  The  enabling  conditions  part 
specifies  the  conditions  under  which  a  transition  is  fired 
when  all  the  conditions  are  evaluated  to  be  true.  Thus, 
an  enabling  condition  is  a  conjunctive  prwlicate  of  all  the 
conditions  and  is  written  2s  px , pj,  •  •  •  where  each  p^ 
is  a  condition.  Note  that  if  the  enabling  condidoos  part 
has  no  statement,  a  transidon  can  always  be  ex^uted.  The 
program  segment  is  a  sa^uence  of  assignment  statements 
sp)ecifying  the  actions  to  be  performed  by  a  transidon. 
An  example  of  the  INRES  protocol  [6]  specifial  using 
this  model  is  shown  in  Figure  1. 

2.2  Data  Flow  Testing 

In  software  engineering,  dataflow  tesdng  is  concerned 
with  testing  the  data  interactions  in  a  program.  Strate¬ 
gies  based  on  dataflow  testing,  which  are  normally  re¬ 
ferred  as  dataflow  sel^tion  criteria,  look  at  interactions 
involving  definitions  for  program  variables  and  subse¬ 
quent  references  that  arc  affected  by  these  definitiims  and 
require  that  certain  such  interactions  be  tested.  Several 
of  these  criteria  have  been  used  in  conformance  testing 


Figure  1;  The  INRES  protocol 


for  testing  the  data  aspect  of  a  protocol.  For  instance,  the 
methods  proposed  in  [3,  4]  use  alUdu^paths  [7];  whereas, 
the  method  proposal  in  [5]  uses  all-simple-OUpaihs  [8]. 
Since  our  method  is  to  augment  a  set  of  paths  generated 
to  cover  a  dataflow  selection  criterion  with  some  subse¬ 
quences  to  cover  the  control  aspect  of  a  protocol,  any  of 
these  dataflow  criteria  can  be  used  in  our  method  for  se¬ 
lecting  a  set  of  paths  to  cover  the  data  interactions.  For 
ease  of  discussing  our  algorithm,  the  all-du-paths  is  used 
in  this  paper. 

Before  discussing  the  all-du-paths  criterion,  several 
terms  need  to  be  defined.  In  dataflow  terminology,  a  vari¬ 
able,  2,  is  said  to  be  a  definition  {def)  in  a  transition,  f, 
if  2  appears  in  the  input  portion  of  f  or  2  appears  at  the 
left  hand  side  of  an  assignment  statement  in  the  program 
segment  of  t.  However,  when  a  variable,  a,  appears  on 
the  right  hand  side  of  an  assignment  statement  j  of  t  or 
in  an  output  statement  ^  of  t,  2  is  both  a  computation-use 
(c-Mse)  variable  of  t  and  a,  respectively.  If  2  is  used  in  an 
enabling  condition  statement  a  of  t,  then  it  is  a  predicate- 
use  ijhuse)  variable  of  i  and  a,  respectively.  In  addition, 
p-usc(t)  denotes  a  set  of  p-use  variables  in  i  and  c-use(t) 
denotes  a  set  of  c-usc  variables  in  <.  Similarly,  p-use{s) 
and  c-usc(s)  are  for  a.  A  global  use  of  2  is  a  use  of  2 
whose  drf  occurs  in  some  other  transitions;  otherwise,  it 
is  a  local  use.  Similarly,  a  global  use  of  2  is  a  def  of  2 
for  which  there  is  a  global  use  in  some  other  transitions; 
otherwise,  it  is  a  local  def. 

A  paA  is  a  sequence  of  transition.  A  path  is  a  simple 
path  if  all  transitions,  except  possibly  the  first  and  the  last, 
are  distinct.  A  path  is  a  loop-free  path  if  all  transitions 
are  distinct.  A  path  (<ii  •  •  • ,  tn)  is  a  def-clear  path  with 
respa:t  to  2  if  •  •  • ,  do  not  contain  def  of  2.  A 
path  (^ii  •  •  •  I  is  a  du-path  with  respect  to  a  variable  2 
if  ti  has  a  global  def  of  2  and  cither  1)  has  a  global 
c-usc  of  2  and  the  path  is  a  def-clear  simple  path  with 


65 


1  Transition  I  def  Variables  |  du-paths 

I 

enc 

I  3 

!  (1.3.4)  1 

I  -  4 

ent 

2  5  -  8 

(1, 2,5.8) 

2  5  ^9 

(1,2.5.9.10) 

anil  mil iM 

num 

2-»5.  2-*5-*6 

(IJ4.6.5,8) 

2  -  5  -►« 

(1, 2.5,8) 

2  5  -9 

(1.24.9,8) 

2-5-7 

■III  mil— 

(1.2,5,9,7.8) 

(l.2,5.7.9,8) 

3 

ent 

(1,3.3.4) 

3-*4 

(1.3,4) 

5 

data 

(1,2,5,9.7.14) 

5-^7  —  9, 5  —  7 

6 

ent 

6  5  —  10 

(1,2,5.6.5.10) 

6  —  5  —  8 

(U4.64,8) 

6  —  5  —  7 

(1,24.6.5.7,10) 

6  —  5  —  9 

(1.2.5,6.5.9.10) 

num 

6-5-8.6  — 5 

(1.2.5.6.5.8) 

6  —  5—7 

(1.24.64.7.8) 

6  —  5—9 

(1,24.64.9,8) 

6— 5— 7— 9 

(1.2,5.6.5. 7.9,8) 

6  —  5  —  9—  7 

(1,2,5,64.9.7,8) 

7 

ent 

7—7 

(1.24.7.7.10) 

7-9 

(12,5.7.9,10) 

7  —  8 

(1.24.7,^) 

7—10 

(1.24.7.10) 

9 

ent 

9-7 

(1Z5,9.7.10) 

9  —  9 

(124.9,9.10) 

9-8 

(124.9.8) 

9-10 

(1.24,9.10) 

Table  1:  Test  Paths  for  Testing  Data  Aspect  of  INRES 


respect  to  x  or  2)  tn  has  a  global  p-use  of  x  and  the  path 
is  a  def-clear  loop-free  path  with  respect  to  z.  The  all- 
du-paths  criterion  requires  that  all  the  du-paths  for  each 
variable  in  a  given  EFSM  be  covend  by  some  paths  in 
a  test  set  Therefore,  selecting  a  set  of  paths  to  fulfill 
the  all-du-paths  criterion  involves:  1)  computing  ail  the 
du-paths  for  each  variable,  and  2)  finding  a  set  of  paths 
to  cover  these  du-paths. 

Table  I  shows  all  the  du-paths  extracted  from  the  IN¬ 
RES  protocol  and  a  set  of  paths  to  cover  these  du-paths. 


Executable  Test 
Path 

Corresponding  Test  Paths 

(1.3V4) 

(1,3,4).  (1.4).  (1.3 ,3.4) 

(1.2,5.7<,10) 

( 1,24, 10),(  1 ,24.7. 10).(  1 ,24.7.7. 1 0) 

(1.2,5.7«.8) 

(1.24.8).(  1.24,7,8) 

(1.24.9M0) 

(1,24»9.10).(  1,24.9.9,10) 

5 

(1,2,5.9«,8) 

(1.24.9.8) 

6 

(124.6.5.7^10) 

(1.24,64, 7.10).(1,2.5,64.10) 

7 

(12.5.64.7«.8) 

(l.2.5.64.8).(1.2.5.64.7,8) 

8 

(1,2,S,64.9«.10) 

(1.24,64.9.10) 

9 

(1.2.5.64.9*.8) 

(1.24.64,9.8) 

10 

(124.7.9*.  10) 

(1,24.7,9,10) 

11 

(1.24.7.9*  .8) 

(1.24,7,9,8) 

12 

(1,24.9.7*.  10) 

(1.24.9,7,10) 

13 

(1.24.9,7*,8) 

(1.24.9,7.8) 

14 

(1.2,5.64,7.9*,8) 

(1.24,64,7,9.8) 

15 

(1,24.64,9.7*.8) 

(1,24.64.9.7.8) 

16 

(1.24.7.9.14) 

(1.24.7,9.14) 

17 

(12.5.9.7.14) 

(1.2.5.9,7,14) 

Table  2:  Executable  Test  Paths  for  Testing  Data  Aspect 
of  INRES 


addition,  since  the  dataflow  technique  is  focused  only  on 
path  selection,  no  clue  is  given  to  how  path  domains  can 
be  generated  for  developing  test  cases  from  these  paths. 

3  Effective  Domain  For  Testing 

In  order  to  conform  that  a  path  chosen  to  cover  some 
data  interactions  in  a  specification  is  indeed  the  same  path 
taken  by  an  lUT  during  execution,  our  method  requires 
that  every  transition  of  the  path  be  checked  for  control 
flow  errors.  This  involves  checking  the  tail  state  of  ev¬ 
ery  transition.  Since  the  tail  states  cannot  be  observed 
directly,  state  check  sequences  must  be  appended  to  the 
respective  transitions.  However,  a  transition  typically  can 
exist  in  different  test  paths;  therefore,  if  all  the  occur¬ 
rences  of  a  transition  must  be  checked,  then  the  length 
of  the  paths  will  be  significantly  increased.  On  the  other 
hand,  it  is  generally  not  sufficient  to  conclude  that  all  oc¬ 
currences  of  a  transition  are  correct  by  simply  testing  one 
of  these  occurrences.  It  is  due  to  the  fact  that  an  occur¬ 
rence  may  be  tested  on  some  aspects  of  a  transition  that 
other  occurrences  cannot  offer.  (This  point  should  be¬ 
come  obvious  after  our  discussion  on  effective  domains.) 


Note  that,  du-paths  that  correspond  to  the  same  subse¬ 
quence  have  only  a  single  entry  in  this  table.  For  instance, 
a  subsequence  1  3  that  is  a  do-path  for  p-use  and  a 

du-path  for  c-use  of  ent  has  a  common  entry  in  the  table. 
The  main  reason  is  that  both  the  du-paths  can  be  covered 
by  the  same  test  path.  Each  du-path  d  is  coveted  by  a 
path  {prt,d,‘poti),  where  pre  is  the  shortest  path  from 
the  initial  state  of  the  protocol  to  the  first  transition  of  d 
and  Tpost  is  the  shortest  path  from  the  last  transition  of  d  to 
the  initial  sute.  Normally,  not  all  paths  in  this  set  are  exe¬ 
cutable  due  to  the  enabling  conditions  along  the  paths.  In 


In  order  to  reduce  the  number  of  testing  for  a  transition, 
strategies  are  needed  for  effectively  selecting  some  oc- 
cunences  of  this  transition  so  that  fault  coverage  is  not 
severely  degraded.  Effective  domain  for  testing  of  a  tran¬ 
sition  in  a  path  provides  a  kind  of  measurement  for  eval¬ 
uating  the  extent  to  which  a  transition  can  be  tested  in  a 
given  path. 

The  concept  of  effective  domain  for  testing  is  based 
on  the  intuitive  relationships  between  dataflow  testing  and 
domain  testing  (9].  The  primary  characteristic  of  domain 
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testing  is  that  a  program’s  input  domain  is  divided  into 
subsc«  with  the  tester  selecting  one  or  more  elements 
from  e^h  subdomain.  An  input  domain  of  a  program  is 
a  subset  o/the  Cartesian  product  of  the  respective  range 
of  values  for  each  input  variable.  An  element  of  an  input 
domain  is  called  an  input  vector.  In  a  way.  dataflow  test¬ 
ing  is  a  type  of  domain  testing.  Dataflow  testing  requires 
the  exercising  of  path  segments  detemi^  by  combina¬ 
tions  of  variable  definitions  and  variable  uses.  The  input 
domain  is  divided  so  that  there  is  a  abdomain  corre¬ 
sponding  to  each  path  covering  the  def-use  associations 
[10].  A  given  subdomain  contains  every  input  vector  that 
causes  the  particular  def-use  associatitms  to  be  satisfied. 
TTiis  subdomain  of  a  path  is  called  the  path  domain  of 
that  path. 


Let’s  call  a  tuple  <  (xi.tii), >.  where 
xi,  •  •  • ,  *n  are  all  variables  of  a  program  and  «,•  €  range 
of  xi  U  {U}.  a  state  vector  of  the  program.  U  is  a  null 
value.  Then,  a  path  domain  defines  an  initial  set  of  state 
vectors  for  a  path.  Based  on  this  set,  the  execution  of 
the  first  transition  in  turn  determines  the  new  set  of  state 
vectors  for  the  second  transition,  and  so  forth.  Each  of 
these  sets  of  state  vectors  before  its  conesponding  transi¬ 
tion  is  executed  is  collectively  called  the  executable  state 
set  of  that  transition.  Note  that  two  transitions  in  a  path 
may  not  be  distinct  transitions  from  a  ^)ecification.  Any 
possible  execution  of  a  transition  (or  rather  an  occurrence 
of  a  transition  from  a  specification)  in  a  path  is  restrictwl 
by  its  executable  state  set.  Specifically,  a  tuple  in  this 
executable  state  set  determines  the  respective  values  of 
those  c-use  and  p-use  variables  of  the  transition.  As  a 
result,  testing  of  this  transition  in  the  path  can  only  be 
done  on  a  certain  combination  of  values  of  its  c-use  and 
p-use  variables.  With  a  given  path,  the  allowed  subsets 
of  Cartesian  product  of  the  possible  v^iies  far  the  p-use 
and  c-use  variables  of  a  transition  is  collectively  called 
the  effective  domain  for  testing  of  that  transition  in  the 
path.  The  effective  domain  fw  testing  provides  a  way  that 
a  tester  can  estimate  how  much  a  transitkin  of  a  specifica¬ 
tion  can  be  tested  by  its  respective  occmences  in  a  given 
path.  Formally,  the  effattivc  domain  for  testing  is  defined 
as  follows: 

Definition  1  For  a  given  path,  p  =  (t^  i  •  •  • .  the  ef¬ 
fective  domain  for  testing  of  a  transition,  in  p,  denoted 

by  is 

1  e  €  execution  state  set  oftff\ 
where  x,-,  6  c-itre(tp<)U  p-use{iyf) 
and <  (Vi,  n),  •  •  • .  (j^. ®»)  >  = 

<  (l/iJ  >  '^il  ‘  >  (%’*  1  ’’ji  )  ^ 
for  1  <  Ji  <  Jj  <  •  •  •  <  ifc  <  9 

In  the  rest  of  this  paper,  if  no  ambiguity  arises  due  to 
paths  or  transitions,  an  effective  domain  for  testing  of  a 


transition  in  a  path  will  simply  be  stated  as  an  effective 
domain. 

To  illustrate  the  idea  of  effective  domains,  let’s  study 
a  set  of  executable  paths  in  Table  2,  which  is  obtained 
from  the  test  paths  as  shown  in  Table  1.  Note  that  not 
all  the  test  paths  in  Table  1  are  executable.  Some  of  the 
inexecutable  paths  can  be  made  executable  while  comput¬ 
ing  thdr  effective  domains.  The  details  will  be  presented 
in  the  next  section.  At  this  moment,  let’s  assume  that  all 
executable  paths  have  been  obtained. 

TaWe  3  shows  the  effective  domains  of  the  executable 
test  paths  (ETP)  numbered  1,  2,  3,  5  and  7  in  Table  2. 
For  simplicity, 

used  to  collectively  denote  the  following  state  vectors 

<  (zi,  t»i),  •  •  •  I  (*<i  ®;)» ‘  ^  ^  ~  ^ ^ 

Similsly,  for  a  transition  U  (says,  having  two  variables 
z  and  y)  from  Figure  1,  »  <  x  ;  WiV  : 

denote  the  »  occurrences 
of  ii  in  a  given  path,  where  vj  and  Uj  are  values  of  x 
and  y.  respectively,  for  the  occurrence  of  U-  ff  P 
has  the  same  value  u  in  all  »  occurrences,  then  it  will 
be  denoted  as  i  <  x  :  [nijba]  •  *  •  b*].  (». «)  >•  F®'’ 
five  paths,  the  effective  domains  for  transition  1  are  not 
shown.  They  are  <  (ent,  U)  >.  In  ETP  1,  each  occur¬ 
rence  of  transition  3  can  be  tested  with  cnl  =  0,  cn<  =  1, 
ci»<  =  2  and  =  3,  respectively.  This  is  because  the 
first  time  transition  3  is  tested,  the  value  of  ent  has  been 
set  to  0  by  transition  1.  Then,  ent  is  increased  by  one 
by  the  statement  enf  :=  ent  +  1.  As  a  result,  the  second 
time  transition  3  is  tested,  the  transition  is  tested  with  the 
value  of  ent  equal  to  1.  The  same  argument  applies  to 
the  third  and  forth  iterations  of  transition  3. 

In  Table  2,  it  also  can  be  seen  that  transition  8  has 
different  effective  domains  in  ETP  3  and  ETP  7.  ETP 
3  has  <  (cni,  4),  (n»m,  1),  :  [2..)  >,  but  ETP  7 

has  <  {ent,4),{num,2),N  :  [3..)  >.  However,  under 
many  circumstances,  a  transition  that  spears  in  two  dif¬ 
ferent  paths  can  have  the  same  effective  domain.  For 
instance,  transition  8  has  the  same  effective  domain  of 

<  (ciU,4),  (nttm,  :  [2..)  >  in  both  E’TP  3  and 
ETP  5,  and  transition  9  has  the  same  effective  domain 
of  <  ent  :  [0][l][2][3],(nttm,  l),dato  :  [o..z]  >  for  E”!? 
5  and  ETP  7.  Therefore,  ETP  3  and  E’TP  5  can  only  pro¬ 
vide  the  same  effectiveness  in  terms  of  ranges  of  values 
for  testing  transition  8,  and  ETP  5  and  ETP  7  can  only 
provide  the  same  for  transition  9. 

Thus,  using  effective  domains,  the  occurrences  of  a 
transition  in  different  paths  can  be  qualitatively  evalu¬ 
ated.  For  a  transition,  our  strategy  is  then  to  choose  a 
sulset  of  occurrences  that  can  adequately  cover  all  the 
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ETP  No. 

Executable  Test  Path 

Effective  Domain  tor  Testing  1 

1 

1,3*  ,4 

3  <  erU  :  [0][lJL2l[3l  > 

4  <  (entr4)  > _ _ _ _ 

2 

1,2,5.7*.10 

2  <  (cnt,0)  > 

5  <  (nom,l ), dote  :[•”*)  >  ,  ^  ,  , 

7  <  ent :  [0][l][2][3],(n«m,l),A' :  [2..), dote  ;  [a..z]  > 

10  <  (ent,4)  >  - 

3 

1,2,5,7«.8 

2  <  (cnt,0)  > 

5  <  (num,  ;  [o..x]  >  ,  ,  ,  .  , 

1  Kent  \  [0][l][2][3],(n«m,l)riV' :  (2..),ciota  :  [a..z]  > 

8  <  (ent,  4).  (num,  1),  N  :  [2-)  > 

5 

1.2, 5.9*. 8 

2  <  (ent.O)  > 

5  <  (num,  1),  data  :  («-x)  > 

9  <  ent :  [0][l][2][3l,(num,l),<ioto  :  [a..x]  > 

8  <  {ent,4)Anum,l),N  :  [2..)  > 

7 

1,2,5.6.5,9’.8 

2  (entfO)  > 

5  <  num  :  [l][2],<iota :  [o^]  > 

6  <  (num,l),(-N‘,l)  > 

9  <  ent :  [0][l][2][3],(num.2),doto  :  [a..x]  > 

8  <  (cnt,4).(num»2).jy  :lor[3..)  > 

Table  3:  Effective  Domain  of  Some  Test  Paths 


distinct  effective  domains.  Since  the  reasoning  for  ef¬ 
fective  domains  is  parallel  to  that  of  domain  testing,  the 
commonly  used  definition  for  distinct  domains  in  the  con¬ 
text  of  domain  testing  is  adopted  in  our  context;  that  is, 
two  domains  are  said  to  be  distinct  if  they  do  not  have 
the  same  set  of  variables  of  which  each  variable  has  an 
identical  domain.  In  this  sense,  two  domains  such  that 
one  is  a  subset  of  the  other  are  still  considered  distinct 

4  Test  Path  Selection 

Assuming  that  a  set  of  paths,  which  may  contain  inexe¬ 
cutable  paths,  has  been  selected  for  fulfilling  the  all-du- 
paths  criterion,  our  test  path  selection  algorithm  will  per¬ 
form  two  more  tasks.  They  are  computing  the  effective 
domains  for  the  paths  and  selecting  the  occurrences  of  the 
transitions. 

4.1  Computing  Effective  Domains 

Since  not  all  the  transitions  in  a  specification  are  included 
in  the  set  of  selected  paths,  those  yet-to-be  selected  tran¬ 
sitions  need  to  be  included  in  this  set.  For  this  purpose,  a 
tour  containing  these  transitions  will  be  added  to  the  set. 

Our  strategy  in  computing  effective  domains  for  a 
given  path  is  to  progressively  computing  the  executable 
sets  for  a  newly  encountered  transition  while  travers¬ 
ing  the  path  and  modifying  the  executable  state  sets  of 
some  traversed  transitions  to  reflect  the  constraints  im¬ 
posed  by  the  newly  visited  transition.  Each  of  the  condi¬ 
tional  and  assignment  statements  imposes  a  certain  con¬ 
straint  on  those  variables  that  appear  in  the  statement. 
The  allowed  values  for  a  variable  will  be  represented  by 


the  allowed  maximum  and  the  allowed  minimum  values 
of  the  variable,  and  a  list  of  constraints  that  specifies  the 
relations  of  this  variable  with  some  other  variables. 

Initially,  the  executable  state  set  of  the  initial  transition 
consists  of  the  Cartesian  product  of  the  variables.  When 
a  transition  is  encountered,  each  of  its  enabling  condition 
t  will  be  evaluated  against  the  current  boundaries  of  the 
involved  variables.  This  evaluation  is  done  by  computing 
the  new  boundary  of  a  selected  variable  v  among  c-use(t). 
The  selection  prefers  input  variables  to  context  variables. 
This  preference  is  to  reduce  the  chances  of  failure  and  the 
number  of  changes  required  for  the  executable  state  sets 
along  the  path.  Based  on  this  computed  boundary  D,  the 
logic  for  further  execution  is  as  follows; 

If  2?  is  not  empty  then 

If  the  new  constraint  conflicts  with  existing  con¬ 
straints 

then  path  may  be  inexecutable 

else  , 

If  i)  is  a  subset  of  the  old  domain  D  of  v 
then  do  nothing 
else  , 

D:=D  n  D 

propagate  D  to  the  executable  state  sets  of  which 
the  corresponding  transitions  have  variables  direct¬ 
ly  or  indirecdy  dependent  on  v  and  update  the 
constraints  of  these  transitions 
else  path  may  be  inexecutable 

For  checking  the  consistency  of  the  new  constraint 
against  the  existing  constraints,  only  those  constraints  di¬ 
rectly  or  indirectly  related  to  those  variable  in  c-use(t) 
need  to  be  examined.  Generally,  the  constraints  for  com¬ 
municating  protocols  are  in  simple  forms,  such  as  linear 
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f  onH  a  lUt  of  the  rclavent  constraints  are  normally 
For  nfancc.  a.  mos.  of  Iho  rinre.  ±e  conrtraln. 
Tffmosf  oVS,.  v»i.bl«  ,n  INRES  has  a  sin*l. 
constraint.  In  addition,  since  the  domains  of  die  vanables 
aT  known,  consistency  of  the  relevant  consoatnts  can 
be  easily  checked  by  the  constraint  satisfaction  problem 
(CSP)  technique  [11]. 


In  the  context  of  communicating  prrtocols.  most  of  the 
inexecutable  paths  can  be  made  executable  if  some  se¬ 
quences  of  transitions  are  inserted  into  the  onpnal  paths. 
This  always  involves  inserting  a  cycle  to  a  particular  state 
of  an  original  path  to  change  the  values  of  t.  A  loop 
that  can  alter  the  values  of  v  will  be  chosen.  The  num¬ 
ber  of  times  this  loop  must  be  unfolded  is  determined 
by  the  number  of  ex«:ution  needed  to  bring  the  values 
of  V  within  D.  This  loop  will  be  unfolded  a  number  of 
times  as  required  and  inserted  into  the  given  test  path. 
The  constraints  of  the  related  transitions  will  be  updated 
accordingly. 


An  assignment  statement  is  not  only  to  define  the  value 
of  its  def  variable,  but  also  to  impose  constraints  on  the 
def  and  c-use  variables  of  the  statement  This  constraint 
will  be  used  to  restrict  some  c-use  variables  if  the  possible 
values  of  the  def  variable  has  to  be  restrictai  based  on 
some  constraints  imposed  by  later  statements-  An  output 
statement  docs  not  impose  any  constraint  on  the  variables 
involved. 


Based  on  an  executable  state  set,  the  corresponding 
effective  domain  can  be  computed  as  the  boundaries  of 
the  p-use  and  c-use  variables,  and  constraints  relevant  to 
these  variables.  It  should  be  noted  that  for  most  of  the 
test  sequence  generation  methods  proposed  in  the  liter¬ 
ature,  the  test  path  selection  and  test  case  selection  are 
separated.  For  those  test  sequence  generation  methods 
based  on  dataflow  criteria,  a  step  which  may  be  manual 
walkthrough  or  computed  automatically  by  some  sym¬ 
bolic  execution  methods,  is  unavoidable  for  computing 
the  path  domains  and  choosing  test  cases  based  on  the 
paths  in  the  given  test  set.  In  our  method,  ^  path  do¬ 
main  as  well  as  the  constraints  on  the  input  vanables  are 
computed.  These  two  pieces  of  information  will  help  in 
generating  input  vectors. 


4.2  Selecting  Occurrences  of  a  Tr^isition 

After  computing  effective  domains  for  the  occurrences  of 
each  transition,  the  next  task  is  to  select  those  occurrences 
that  have  distinct  effective  domains  for  a  transition.  Iden¬ 
tical  effective  domains  of  a  transition  are  its  occurrences 
that  have  identical  boundaries  and  constraints  for  the  rel¬ 
evant  variables.  However,  some  care  must  be  taken  to 
reduce  the  overall  length  of  the  result«l  test  paths.  There 


are  two  reduction  rules  that  can  be  employed  to  reduce 
the  number  of  occurrences  of  a  transition  before  making 
selection.  The  fint  rale  is  to  be  applial  to  a  set  of  occur¬ 
rences  that  have  distinct  domains,  and  the  second  rule  is 
to  be  applied  to  a  set  of  occurrences  that  have  identical 
effective  domains.  The  first  reduction  rule  is  as  follows; 

R1  Redundawt  DoDaalns:  An  effective  domain,  EDfj,t 
can  be  eliminated  if  there  exists  some  EDfi,t  (says 
n)  for  1  <  » <  »  and  j  such  that 

where  U  is  defined  for  a  tuple  of  range  of  values  as 
follows: 

U?=i  <  Diu •••,!>«»  >=<  UjLi  Ai>  •  •  • . UjLi Am  > 

In  Rl,  the  effective  dmnain  EDf^,t  is  made  redundant 
by  the  n  effective  domains  EDfi,t  since  testing  of  t  in 
Pj  with  any  possible  values  for  variables  of  f  before  i  is 
executed  can  also  be  conducted  with  some  pi. 

Before  describing  the  second  reduction  rule,  let  s  dis¬ 
cuss  the  problems  of  appending  state  check  sequences 
to  transitions.  For  each  transition,  state  check  sequences 
must  be  appended  to  the  tail  states  of  those  selected  oc¬ 
currences.  To  ensure  that  the  fault  coverage  of  these  paths 
is  not  severely  Waited  after  state  check  sequences  are  in¬ 
troduced.  these  newly  added  state  check  sequences  must 
be  selKted  with  care.  In  general,  introducing  more  tran¬ 
sitions  to  a  path  of  an  FSM  cannot  degrade  the  fault  cov¬ 
erage  of  that  path,  but  introducing  more  transitions  in  a 
path  of  an  EFSM  may  depde  the  fault  coverage  of  that 
path.  A  simple  example  is  that  a  newly  introduced  seg¬ 
ment  may  redefine  some  variables  in  a  path  that  is  to 
cover  a  def-cletr  segment  Three  types  of  state  check  se¬ 
quences  can  be  used  to  serve  the  purpose  of  identifying  a 
tail  state.  The  preference  that  it  is  chosen  for  a  tail  state 
is  according  to  the  following  order. 

Type  1  An  unique  check  sequence  such  as  an  UIO 
sequence  for  a  slate  such  that  this  sequence  overlaps 
with  the  subsequent  transitions. 

Type  2  A  sequence  that  concatenates  1)  a  unique 
check  sequence  a  sute  with  2)  a  transfer  sequence 
to  bring  the  flow  back  to  the  tail  state,  and  does  not 
redefine  the  def  variables  of  any  def-use  association 
that  the  (wiginal  path  is  supposed  to  cover. 

Type  3  A  sequence  that  concatenates  a  unique  check 
sequence  for  a  state  with  a  transfer  sequence  to  bring 
the  flow  back  to  the  initial  state  and  then  back  to  the 
tail  state. 

Obviously,  stale  chedt  sequences  of  Type  1  do  not  alter 
the  effective  domains  of  transitions  in  a  path.  In  addition. 
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States 

UIO  Sequences 

DISCONNECTED 

1 

WAIT 

3  or  2 

CONNECTED 

5 

SENDING 

7  or  6  or  8  or  9 

Table  4:  State  Check  Sequences  for  INRES 

Type  1  sequences  do  not  increase  the  length  of  a  path. 
Type  3  requires  that  all  the  variables  be  reset  after  a  state 
check  sequence  is  applied.  It  is,  thus,  less  preferred  than 
the  other  two  types  of  check  sequences. 

The  second  reduction  rule  is  based  on  the  Type  1  state 
check  sequences.  It  deals  with  a  set  of  occurrences  of 
a  transition  that  have  an  identical  effective  domain.  If 
there  exists  an  occurrence  in  this  set  that  has  an  UIO  of 
the  transition  overlapping  with  its  path,  this  occurrence 
can  be  chosen  as  the  representative  for  this  set  of  occur¬ 
rences.  However,  since  this  occurrence  has  an  UIO  of  the 
transition  overlapping  with  the  path,  no  extra  checking  is 
needed  at  all.  Thus,  the  second  rule  can  be  formulated  as 
follows: 

R2  Overlapping  Transitions:  No  checking  is  needed 
for  a  set  of  occurrences  of  a  transition  t  that  has  an 
identical  effective  domain  if  there  exists  a  path  pi  in 
this  set  such  that  pi  contains  a  subsequence  (t,  U), 
where  U  is  a  state  check  sequence  for  the  tail  state 
of  i. 

An  application  of  this  rule  to  some  paths  shown  in 
Table  2  is  as  follows:  As  shown  in  Table  3,  both 
ETP  2  and  ETP  3  have  the  same  effective  domain  of 
<  (cnf,  3),  (»«m,  1),  iV  :  [2..),  data  :  [o..z]  >  for  the 
forth  iteration  of  transition  7.  By  applying  R2,  the  forth 
iteration  of  transition  7  in  ETP  2  needs  not  be  checked. 
It  is  because  ETP  3  contains  a  subsequence  (7,8).  As 
shown  in  Table  4,  transition  8  is  an  UIO  of  the  tail  state 
of  transition  7. 

Some  caution  of  words  must  be  given  here.  By  apply¬ 
ing  R1  to  a  set  of  test  paths,  the  fault  coverage  for  the 
resulting  set  cannot  be  degraded.  However,  applying  R2 
may  degrade  the  fault  coverage  of  a  set.  According  to 
[12],  the  fault  coverage  of  UIOs  for  a  set  of  transitions 
can  be  degraded  if  these  UIOs  are  overlapped  with  the 
subsequent  transitions  in  a  test  path  that  is  supposed  to 
test  this  set  of  transitions.  Since  the  tail  state  of  a  tran¬ 
sition  is  always  tested  a  number  of  times  by  our  method 
in  different  occurrences,  the  chances  of  degrading  are  re¬ 
duced.  Nevertheless,  Miller  and  Paul  [13]  pointed  out 
that  if  there  is  no  converging  state  in  a  path,  fault  cov¬ 
erage  is  not  compromised  by  overlapping  the  UIOs  of 
the  tail  states  of  the  intermediate  transitions.  Converg- 


ETP  No. 

Final  Test  Path 

1 

(l,3’,2,13,l,3V4,l,lZJ 

2 

(1,2,5,7^,10,1,12) 

3 

4 

(1,2,5,7<,8,1.12) 

(1,2,5,9«,10) 

5 

(1,2, 5,9V  8) 

6 

(1,2,5,6,5,7«,10) 

7 

(1,2,5,6,5,7«,8,1,12) 

8 

(l,2,5,a,5,9M0) 

9 

(1,2, 5, 6, 5,9V  8) 

10 

(l,2,5,7,9»,10) 

11 

(1,2, 5, 7, 9*, 8) 

12 

(1,2, 5, 9,7V  10) 

13 

(1,2,5,9,7V8) 

14 

(1,2, 5,6, 5, 7, 9*,  8) 

15 

(1,2, 5,6, 5,9, 7V8) 

16 

(1,2,5,7,9,14,1,12) 

17 

(1,2,6,9,7,14) 

18 

(1,3,12,1,12,11,1,2,13,1,12) 

Table  5;  A  Final  Set  of  Test  Paths  for  INRES 


ing  states  are  those  states  which  have  outgoing  transitions 
with  identical  input/output  that  go  to  the  same  state. 

After  applying  these  two  rules,  it  will  be  easy  to  de¬ 
cide  for  which  the  occurrences  of  a  transition,  state  check 
sequences  are  needed.  For  those  domains  that  have  only 
one  occurrence,  these  occurrences  will  be  checked.  For 
each  of  those  domains  that  have  more  than  one  occur¬ 
rences,  only  one  is  needed.  Of  all  these  selected  occur¬ 
rences,  TVpe  2  or  Type  3  sequences  can  be  used  for  each 
of  them. 

4.3  An  Example 

Based  on  the  aforementioned  algorithm,  a  final  test  set 
that  can  test  both  the  data  flow  and  the  control  flow  of 
INRES  is  given  in  Table  S.  The  state  check  sequences 
are  underlined.  Except  that  the  state  check  sequences  for 
transition  3  in  ETP  1  are  for  the  WATT  state,  the  others 
are  all  for  the  DISCONNECTED  state.  Even  though  tran¬ 
sition  8  appears  8  times,  the  tail  state  of  transition  8  is 
only  tested  at  ETP  3  and  ETP  7.  Similarly,  the  tail  state  of 
transition  10  is  tested  once  at  test  sequence  2  even  though 
transition  10  appears  6  times.  Inde^,  transitions  8  and 
10  use  the  same  state  check  sequence;  it  is  (1, 12)  and  is 
of  Type  2.  Transition  1  is  an  UIO  of  DISCONNECTED 
and  transition  12  is  a  transfer  sequence  to  bring  the  flow 
back  to  DISCONNECTED.  This  same  state  sequence  is 
also  used  for  testing  transition  13  in  ETP  13  and  transition 
14  in  ETP  16. 

In  ETP  I,  the  last  execution  of  transition  3  that  has  an 
effective  domain  of  <  {ent,  3)  >  is  tested  by  a  TVpe  3 
state  check  sequence.  This  sequence  consists  of  transition 
2  and  a  subsequence,  (13,1,3**).  Note  that  the  correctness 
of  transition  3  is  checked  at  the  first  three  iterations  by 
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a  Type  1  state  check  sequence  which  is  (3).  Since  tran¬ 
sition  3  is  tested  in  ETP  I  with  an  effective  domain  of 
<  {cnt,  U)  >,  it  is  not  tested  in  ETP  18  again. 

5  Conclusion 


tail  state  is  a  converging  state  more  than  once  if  its  occur¬ 
rences  have  the  same  effective  domain.  In  our  example,  if 
transition  7  is  not  an  UIO  for  SENDING,  then  our  method 
will  only  check  transition  7  for  its  four  iterations  in  ETP 
2.  However,  the  method  of  [15]  will  have  to  check  all 
occurrences  of  transition  7  in  various  paths. 


In  this  paper,  an  approach  is  proposed  for  generating  paths 
that  check  both  data  and  control  flow  of  a  protocol.  After 
generating  a  set  of  paths  to  cover  a  dataflow  selection  cri¬ 
terion,  our  method  uses  the  concept  of  effective  domains 
to  selectively  augment  the  transitions  in  the  set  with  state 
check  sequences  so  that  the  control  flow  can  be  ensured 
and  the  dataflow  coverage  can  still  be  preserved.  Our 
method  also  computes  path  domains  for  the  paths  and 
makes  some  inexecutable  paths  executable. 

In  terms  of  fault  detection  capability,  our  method  pre¬ 
serves  the  fault  coverage  of  the  dataflow  analysis  tech¬ 
nique  since  the  def-use  associations  of  a  criterion  that  a 
selected  path  is  supposed  to  cover  are  not  disturbed  by 
any  of  the  three  types  of  state  chtxk  sequences.  In  addi¬ 
tion,  our  approach  also  ensures  that  every  transition  and 
its  tail  state  is  tested  at  least  once.  This  is  the  minimum 
requirement  in  the  conventional  sense  for  checking  con¬ 
trol  errors.  However,  as  mentioned  in  Section  3,  it  is  not 
sufficient  for  the  EFSM.  The  resulting  test  sets  further  en¬ 
sure  that  every  distinct  effective  domain  is  covered.  For 
a  transition,  our  algorithm  only  ^ypends  state  check  se¬ 
quences  to  those  occurrences  that  have  distinct  effective 
domains,  thereby  reducing  the  number  of  state  check  se¬ 
quences  to  be  appended  to  a  test  set. 

To  the  best  of  our  knowledge,  dicre  m  only  two  works 
[14,  15]  that  have  dealt  with  the  issue  of  combining  con- 
U'ol  flow  testing  with  dataflow  t^dng.  But,  neither  has 
proposed  ways  for  computing  path  domains  fOT  the  re¬ 
spective  paths.  In  [14],  a  combiniog  m^iod  is  used  for 
generating  a  test  path  for  a  given  mutant.  Basically,  this 
method  uses  segment  overlapping  t^hnique  to  shorten 
the  overall  length  of  a  test  path  and  only  requires  that 
a  transition  be  tested  once.  As  mettdoaed  in  Section  3, 
a  transition  in  an  EFSM  generally  must  be  tested  more 
than  once  for  revealing  errors  that  may  only  occur  in  cer¬ 
tain  paths.  In  [15],  a  method  is  proposed  to  augment  a 
set  of  paths  generated  to  cover  the  all-du-paths  criterion 
with  cyclic  characterizing  sequences  (CCS).  A  CCS  is 
the  same  as  a  Type  2  state  check  sequence.  By  applying 
Miller’s  result  reported  in  [13]  for  tbe  FSM,  this  method 
only  inserts  a  CCS  to  the  last  state  rf  a  path  if  there  is  no 
converging  state  along  the  path.  lo  the  case  that  several 
converging  states  appear  in  a  path,  each  converging  state 
is  replaced  by  a  CCS.  In  our  method,  these  two  cases 
are  taken  care  of  by  the  Type  1  md  Type  2  sequences. 

In  addition,  our  method  do  not  check  a  transition  whose 


Regarding  our  future  work,  strategies  are  being  inves¬ 
tigate  for  using  the  underlying  control  structures  of  a 
specification  to  reduce  the  number  of  test  cases  needed 
for  data  flow  testing. 
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Abstract 

A  method  is  proposed  to  transform  test  case  generation  problem  to  protocol  validation 
problem.  Protocol  validation  has  been  studied  for  years  and  many  validation  tools  are 
available.  By  transforming  a  test  case  generation  problem  into  a  protocol  validation 
problem,  a  protocol  validation  tool  can  be  used  to  generate  test  cases.  The  method 
can  be  implemented  in  a  very  short  period  of  time.  The  complexity  of  the  proposed 
method  in  searching  for  a  test  case  is  0{n)y  where  n  is  the  number  of  system  states  in  the 
specification. 


1  Introduction 

Test  case  generation  (TCG)  for  Finite  State  Machines  (FSM)  has  been  studied  for  years, 
and  fruitful  results  have  been  produced  [1,  2,  3,  4].  The  FSM  is  a  simple  model  that 
ignores  the  data  flow  of  a  protocol  and  concentrates  on  the  protocol’s  control  flow.  In 
other  words,  it  simplifies  a  protocol  into  a  state-transition  machine.  However,  ignoring 
the  data  flow  of  the  protocol  often  removes  many  interesting  properties  from  the  protocol. 
As  an  example,  it  is  hard  to  specify  a  simple  protocol  like  Go-Back-N  in  FSM  without 
losing  those  important  properties  associated  with  the  protocol’s  window  size. 

Therefore,  most  protocol  specifications  aire  written  in  more  sophisticated  models,  such 
as  Extended  Finite  State  Machine  (EFSM)  [5],  Estelle  [6],  LOTOS  [7],  or  other  program¬ 
ming  languages.  These  models  arc  called  extended  models  in  this  paper  with  respect  to 
the  basic  FSM  model.  To  be  more  practical,  a  test  case  generation  method  must  be  able 
to  generate  test  cases  from  extended  models.  However,  the  difficulty  is  that  to  test  an 
extended  model,  one  needs  to  test  not  only  the  control  flow,  but  also  the  data  flow  of  the 
protocol.  Testing  both  control  and  data  flows  is  considered  a  challenging  problem  and 

•Research  reported  herein  was  supparted  by  U.S.  Army  Research  Office,  under  contracts  No.  DAAL03- 
91-G-0093  and  No.  DAAL03-92-G-0184.  The  views,  opinions,  and/or  findings  contained  in  this  paper  arc 
those  of  the  authors  and  should  not  be  construed  as  an  official  Department  of  the  Army  position,  policy 
or  decision. 
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not  much  work  has  been  done  so  far.  Some  references  about  the  test  case  generation  for 
the  extended  models  can  be  found  in  [8,  9,  10,  11,  12,  13,  14], 

A  test  case  can  be  used  for  detecting  a  certain  type  of  faults,  which  are  called  the  fault 
models  of  the  test  case  [15].  Because  of  the  complexity  involved  in  searching  test  cases 
for  extended  models,  it  is  believed  that  fault  models  should  be  used  as  a  guide  to  simplify 
the  search  [16,  17].  Traditionally,  a  TCG  method  is  dedicated  to  generating  test  cases  for 
certain  fixed  fault  models.  On  the  contrary,  a  TCG  method  based  on  fault  models  takes 
both  a  protocol  specification  and  a  given  fault  model  as  input  and  generates  a  test  case 
for  the  fault  model.  An  I/O  sequence  can  be  used  as  a  test  case  if  the  spedfication  and 
the  fault  model  behave  differently  when  applying  the  I/O  sequence. 

A  fault  model  is  usually  a  modification  of  the  original  protocol  spedfication,  and  can 
be  described  by  the  same  model  used  to  define  the  protocol  specification.  For  example, 
Figure  1  is  the  sender  of  a  Go-Back-N  protocol  specified  in  EFSM  with  a  window  size 
equal  to  four  {W=i).  A  fault  model  like  the  one  drawn  in  Figure  2  has  a  window  size 
being  set  to  five.  Note  that  only  the  action  associated  with  the  first  transition  is  changed^ . 

Generating  test  cases  based  on  a  given  fault  model  has  the  following  advantages: 

1.  Every  test  case  has  a  well  defined  test  purpose.  That  is,  the  types  of  errors  a  test 
case  can  detect  is  automatically  provided.  In  addition,  those  who  test  a  protocol 
implementation  with  the  test  case  will  have  the  confidence  that  the  fault  described 
by  the  fault  model  does  not  exist  in  the  implementation. 

2.  It  reduces  the  complexity  of  finding  a  test  case.  Instead  of  searching  aimlessly,  a 
TCG  method  can  use  a  given  fault  model  as  a  goal  to  direct  the  search. 

3.  Users  can  chose  to  test  critical  faults  first,  and  test  minor  errors  later. 

4.  It  is  more  flexible  than  the  traditional  methods.  The  traditional  TCG  methods  have 
fixed  fault  models  embedded  in  them.  If  a  critical  fault  does  not  contain  in  the  fault 
models,  the  traditional  TCG  methods  cannot  effectively  test  this  fault. 

•The  EFSMi  utcil  in  this  paper  have  five  types  of  actions  associated  with  their  transitions. 

1.  Assignment:  IF  :=  4  assigns  value  4  to  variable  W. 

2.  Input:  RlAck{A)  receives  message  Ack  whose  argument  is  assigned  to  variable  A. 

3.  Output:  mM sff(5[5fR],  5m)  sends  a  message  Msg  with  arguments  B[5m]  and  5m,  where  5[5m] 
is  the  Sjjvth  element  in  array  B. 

4.  Condition:  A  transition  with  action  k  <>  5m  can  only  be  executed  when  k  and  5m  are  not  equal. 

5.  Timeout  (T/0):  The  transition  will  be  executed  after  a  certain  amount  of  time  expires. 
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In  this  paper,  the  problem  of  TCG  based  on  fault  models  is  transformed  into  a  protocol 
validation  (PV)  problem.  Protocol  validation,  which  is  used  to  detect  design  errors  in  a 
protocol  specification,  has  been  studied  for  years.  While  many  protocol  validation  tools 
have  been  made  available,  automatic  test  case  generators  are  still  hard  to  find.  Therefore, 
a  method  is  proposed  to  transform  TCG  to  PV  so  that  available  validation  tools  can  be 
used  to  generate  test  cases.  It  will  also  be  shown  later  that  the  transformation  method 
not  only  can  be  used  to  generate  test  cases  for  weak  conformance,  but  also  can  be  used 
to  generate  test  cases  for  strong  conformance,  functional  testing,  and  multiple-module 
specifications. 

It  is  well  known  that  there  is  a  so  called  state  explosion  problem  for  protocol  validation, 
which  means  that  the  number  of  states  generated  by  a  protocol  validation  tool  increases 
exponentially  when  the  protocol  specification  becomes  more  complicated.  The  method 
proposed  in  this  paper  takes  a  protocol  specification  and  a  fault  model  as  its  input  and 
generates  a  combined  system  to  be  fed  into  a  protocol  validation  tool.  It  is  also  shown 
in  this  paper  that  the  complexity  of  the  combined  system  is  0{n)  if  the  number  of  global 
states  in  the  original  protocol  specification  is  n.  Therefore,  the  state  explosion  problem 
will  not  occur  as  long  as  it  will  not  occur  in  the  original  specification. 

The  organization  of  this  paper  is  as  follows.  In  Section  2,  the  transformation  from  the 
test  case  generation  problem  to  the  protocol  validation  problem  is  proposed.  The  same 
section  also  discusses  how  the  transformation  to  weak  and  strong  conformance,  functional 
testing,  and  multiple- module  protocols  can  be  applied.  In  Section  3,  the  implementation  of 
the  test  case  generator  is  introduced,  and  some  experimental  results  are  discussed.  Finally, 
the  complexity  of  the  test  case  generator  is  discussed  in  Section  4  and  a  conclusion  is  given 
in  Section  5. 

2  Transforming  TCG  to  PV 

2.1  The  Transformation 

A  test  case  for  a  fault  model  is  an  I/O  sequence  that  detects  the  discrepancies  between 
the  fault  model  and  the  protocol  specification.  That  is,  the  test  case  is  a  possible  I/O 
sequence  for  one,  but  not  for  the  other.  For  example,  an  I/O  sequence  can  be  used  as  a 
test  case  if  it  can  be  generated  from  the  protocol  specification,  but  cannot  be  reproduced 
from  the  fault  model.  In  other  words,  if  a  protocol  implementation  contains  an  error 
described  by  the  fault  model,  applying  the  input  sequence  of  the  test  case  to  the  imple¬ 
mentation  will  produce  an  unexpected  output  because  the  I/O  sequence  cannot  appear 
in  the  implementation. 

The  task  is  to  find  an  I/O  sequence  that  can  only  be  applied  to  either  the  protocol 
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specification  or  the  fault  model,  but  not  both.  Let  P  (for  Primary)  be  an  automaton  that 
describes  either  the  protocol  specification  or  the  fault  model,  and  let  5  (for  Secondary)  be 
an  automaton  that  describes  the  other.  If  P  and  S  are  executed  synchronously,  whenever 
P  makes  a  certain  output,  5  must  make  the  same  output;  otherwise,  it  will  be  a  discrep¬ 
ancy.  Similarly,  if  P  requires  a  certain  input,  S  must  wait  for  the  same  input;  otherwise, 
it  will  be  a  discrepancy  as  well. 

The  idea  here  is  to  construct  a  system  that  will  deadlock  when  P  and  5  take  different 
input  or  output  actions.  The  combined  system  can  be  fed  into  a  protocol  validation  tool. 
When  the  validation  tool  signals  a  deadlock  error,  one  can  trace  through  the  execution 
path  that  causes  the  deadlock.  Then,  the  I/O  events  generated  by  the  path  can  be  used 
as  a  test  case. 

The  first  step  is  to  modify  automaton  P,  Let  P'  be  an  automaton  the  same  as  P, 
except  for  the  following  differences: 

1.  For  every  output  action  in  P,  make  the  same  output.  Then,  wait  for  a  resume 
signal. 

2.  For  every  input  action  in  P,  output  a  message  that  requests  the  input  first.  Then, 
wait  for  the  input. 

3.  For  every  timeout  In  P,  output  a  message  labeled  T/Q.  Then  wait  for  a  resume 
signal. 

Next,  make  an  automaton  S'  similar  to  5  except  for  the  following  changes: 

1.  For  every  output  action  in  5,  input  a  message  first.  If  the  input  message  is  the  same 
as  the  message  to  be  output,  output  an  ok  signal. 

2.  For  every  input  action  in  5,  input  the  message.  Then,  output  an  ok  signal. 

3.  Remove  every  timeout  in  5. 

Finally,  let  M  {{ot  Monitor)  be  an  automaton  communicating  with  P'  and  S'.  M 
provides  a  variable  for  each  parameter  of  every  input  action  in  P' .  The  variables  arc 
initialized  to  their  lower  bound  values.  Monitor  Af  performs  the  following: 

1.  Increment  the  value  of  a  variable  by  one  nondetenninistically,  unless  an  upper  bound 
is  reached. 

2.  When  an  output  from  P'  is  received,  pass  the  message  to  S'  and  wait  for  an  ok 
signal  from  S'.  After  receiving  the  ok  signal,  send  a  resume  signal  to  P',  and  record 
the  output  event. 
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Table  1:  Modification  made  by  P',  S',  and  M 


3.  When  P'  asks  for  an  input  message,  send  the  message  to  S'  first.  After  receiving  a. 
ok  from  S',  send  the  same  message  to  P'  and  record  the  input  event. 

4.  When  P'  outputs  a  T/0  message,  send  resume  signals  to  P',  and  record  the  timeou 
event. 


The  .hove  modificatioa  is  summerieed  in  T.ble  L  Let  I  (for  /ntejmted)  be  an  inte 
pated  system  that  contains  P‘,  S‘,  and  U.  Then,  I  will  deadlock  i£  P  generates  som. 
I/O  sequences  that  cannot  be  reproduced  by  S.  This  can  be  brieHy  proved  as  Mows. 

1.  H  S  ctmnot  generate  the  same  message  output  by  P,  S'  will  stop.  Without  recerv. 
ing  any  ok  signal,  M  will  be  blocked  and  wiU  not  send  the  t.stm.  signal  to  P 
Therefore,  P'  will  be  blocked  as  well. 

2  H  5  will  not  receive  the  same  input  as  P  does,  S'  will  be  blocked  and  no  ok  signal 
wiU  be  send.  Therefore,  if  will  be  blocked  and  P'  will  never  recerve  the  r.sme. 
signal.  The  system  deadlocks. 


The  protocol  mnong  U,  P‘  and  S'  is  illustrated  in  Figure  3.  When  P  sends  a  message 
to  M,  M  passes  it  to  S'.  If  the  nisg  is  also  a  message  that  S  “  '"‘‘I’"'’/ 

J  send  an  ok.  Upon  receitdng  the  ok  signal,  M  sends  a  r.sn..  to  F'  (F-t”" J*)-  On 
the  other  hmtd,  if  P‘  needs  to  receive  a  certain  message,  it  sends  a  request  to  If.  Upon 
receiving  the  request,  M  sends  the  message  to  S'  first.  B  ok  rs  recerved  If  sends  the 
requested  message  to  P'  (Figure  3b).  The  timeout  message  between  P  and  M  are  used 
to  record  the  timeout  event,  and  will  not  affect  the  overall  execut.on  of  the  system. 

An  example  of  the  trmrsformation  is  shown  in  Figure.  4  to  6.  Figure  4  is  the  primwy 
automaton  P'  modified  from  the  Go-Back-N  protocol  specllication  in  Figure  1.  The 


Figure  3:  Communication  among  M,  P  and  5 


shaded  arrows  and  circles  are  the  transitions  and  states  being  changed  accor^ng  to  he 
rules  described  in  Table  1.  Figure  5  is  the  secondary  automaton  S  modified  from  the 
fault  model  shown  in  Figure  2.  Monitor  M  for  Figures  4  and  5  is  drawn  m  Figure  6.  Note 
that  aU  the  I/O  events  in  P'  and  S'  are  changed  into  communication  between  P  and  M, 

and  between  S'  and  M,  respectively. 


When  a  protocol  specification  and  its  fault  models  are  specified  by  a  formal  model 
(such  as  FSM,  EFSM,  Estelle,  LOTOS,  SDL,  Petri-Net,  Promela,  etc.),  it  is  tnvial  to 
transform  P  and  S  into  P'  and  S',  respectively.  It  is  also  straightforward  to  construct 
the  monitor  M.  Automata  P',  S'  and  M  can  be  fed  into  a  vaHdation  tool  for  the  forma^ 
model  and  a  deadlock  can  be  found  if  there  is  an  I/O  sequence  that  is  possible  for  P  bu 
cannot  be  generated  by  S.  By  retracing  the  path  leading  to  the  deadlock,  monitor  M  wiU 
record  the  I/O  events  along  the  path.  The  recorded  I/O  event  sequence  can  then  be  used 


SIS  a  test  case. 


2.2  Weak  and  Strong  Conformance 

There  are  two  types  of  conformance  between  a  protocol  specification  and  its  implemen¬ 
tation.  The  weak  conformance  indicates  that  a  protocol  implementation  should  perform 
every  function  defined  in  its  specification.  In  other  words  things  that  ought  to  happen 
should  happen.  The  strong  conformance  imposes  an  additional  constrain  which  states 
that  a  protocol  implementation  cannot  have  any  behavior  not  defined  by  the  protocol 
specification.  That  is,  tlungs  that  cannot  happen  must  not  occur. 

A  fault  model  violating  the  weak  conformance  cannot  perform  some  functions  defined 
by  the  protocol  specification.  In  other  words,  there  exists  an  I/O  event  sequence  that 
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ca»  be  .enereted  by  the  speciScelion,  but  CMUot  happen  in  the  fault  model.  To  Jenetate 

St  ^0  for  the  fault  model,  one  cm.  use  the  protocol  specilicat.on  as  the  pnmary 
automaton  P,  use  the  fault  model  as  the  secondary  automaton  5,  apply  the  transfotma  .on 
in  Section  2.1.  and  feed  the  resultinis  system  I  into  a  protocol  vahdat.on  tool. 

A  fault  model  that  violates  the  stronj  conformance  has  some  enecution  paths  that  sue 
not  specified  in  the  protocol  specification.  That  is,  some  I/O  sequence  gener^ed  by  the 
fault  model  can  never  happen  in  the  specification.  Thus,  d  one  use  the  fault  model  as 
the  primary  automaton  P  and  use  the  specification  as  the  secondary  automaton  S  on. 
can  find  a  test  case  with  the  method  described  in  Section  2.1.  When  the  input  of  he 
test  case  is  applied  to  a  protocol  implementation,  and  an  enpected  output  appears,  the 
implementation  must  contain  an  error  described  by  the  fault  model. 

It  is  possible  that  a  fault  model  violates  both  weak  and  strong  conformance.  In  this 
case,  treating  the  protocol  specification  as  either  the  primary  or  the  secondary  will  work^ 
Sometimes,  however,  it  is  difficult  to  teU  whether  a  fault  model  violate,  the  weak  or  strong 
conformance.  In  snch  a  case,  if  on.  method  cannot  find  a  test  case,  the  other  must  be 

tried. 


2.3  Functional  Testing 

It  is  useful  to  create  test  cases  that  ensure  the  corrmdness  of  certain  behavior  in  the 
protocol  specification.  Such  “behavior”  is  often  cjled  a  /unclson  or  a  mjumcmmd  of  the 
protocol  specification.  For  example,  a  rmiuirmnent  of  the  Go-Back-N  protocol  .n  Figure  1 
can  be  “there  are  no  more  than  three  messojes  in  the  chonnel  ol  ony  Jiuen  time. 

In  order  to  test  if  a  protocoi  implementation  conforms  with  the  requirement,  a  fauit 
model  that  violates  the  requirement  is  constructed.  However,  since  a  requirement  usu  y 
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.  i.. .  po.tio„  or  .ho  ;>>'f 

co„..,uc.  o  t.«l.  o.»d«l  &<>“  o».i.o  r«o‘~»l  „qohomo„^ 

can  be  created  by  including  only  those  transations  J  paragraph 

p.  „..p.e,  .  ‘  r.'hXo,  .hore  is  no  res.HCion  on  ho. 

'“nr-si;. ^  ho  son.  .o  .ho  roooivo,  cons.on.ivol,  hofooo  .ho  sondo.  .oco.vos  nn 

arVnowledgment. 


k:«0 

W:»4 


]l7Ack(A) 


xtMsg(B(k] « k) 


kj*(k+l)  moA  w 


Figuro  7:  A  tanl.  modol  Iha.  sonds  mor.  than  throe  mossogo.  at  a  timo. 

The  fault  model  In  Fi^re  ‘‘;^^rll°TheTot‘e°  it  “u“I 

implen.ent...on,  »  .t  violate,  the  i  ^  ^  .econdary.  Since  the  fault 

as  a  primary  speciiicaUon,  some  I/O  events  in  .he 

“el:™  eais.  m  the  fa^t  modol.  Honco,  a  modihca.ion  of  .he  .ranstorma.ion 
described  in  Section  2.1  should  be  noted  as  follows. 

•  To  change  P  (S)  into  P'  (S'): 

*  ♦  ,.+;nn  exists  in  both  P  and  5,  Mow  the  procedure  in 

1.  If  an  input  or  output  action  exists  in  uu 

Section  2.1. 

a  —  th»t  ..«sts  only  in  P  (S),  send  the  output  to  M  and 

2.  For  every  output  message  that  exists  oniy  in  j, 

wait  for  a  resua®  signal  from  Af. 

♦K.t  (.lists  only  in  P  (5),  send  an  request  for  the 

3.  For  every  input  message  that  exists  omy  m  rj^ 

input  to  M  and  wait  for  the  inpat  event  from  M. 

•  To  construct  M: 

a  ♦  that  exist  in  both  P  and  S,  follow  the  pro- 

1.  For  those  input  or  output  actions  that  exist 

cedure  in  Section  2.1. 

2.  H  an  output  message  that  exist,  only  in  F  (5)  »  recrived  from  F'  (S'),  record 
the  output  event  and  send  a  resume  signal  to  P  )• 

a  r  •  F  Fhmt  evists  only  in  P  (S)  is  received  from  P'  (S'),  record 

3.  If  a  request  for  mput  that  exists  omy  m  i-  v-^ ;  rw  /  c'\ 

the  input  event  and  send  the  input  message  to  P  (b  ). 


-158- 


1  •  P  or  5,  the  monitor  M  will 

u  ;f  an  input  or  output  message  exists  only  m  r 

::r  v'”Tp“  '• 

nd  release  the  automaton  that  generates  the  even^  modified  according  to  the 

-u  ooiy  i.  “V"  -  i»  8. 

p„c.dur..  TK.  -uto*  EF  •  9  .nd  1  show  .he 

‘t:  Ihod  .  .eco  .nd  .h.  on.  .»  s.c..oo  2X 


II7K«»U 


niR«qtAck) 
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Figure  8;  The  primary 


P'  from  the  fault  model  m  Figure  7. 


FiKure  9:  The  secondary  S'  from 


the  specification  in  Figure  1. 


Figure  10:  The  monitor  M  from  the  fault  model  in  Figure  7  and  the  specification  in 
Figure  1. 

2.4  Test  Case  Generation  for  Multiple  Modules 

Test  cases  can  also  be  generated  for  multiple  modules  using  this  method.  For  example, 
one  may  want  to  test  how  a  protocol  containing  a  sender  and  a  receiver  operates  when 
connected  with  a  network.  The  whole  system  can  be  modeled  like  the  one  in  Figure  11. 


Figure  11:  A  multiple-module  specification 
A  modification  should  be  made  when  testing  a  multiple- module  specification: 

•  Only  those  I/O  actions  that  are  used  to  communicate  with  the  outside  world  should 
be  monitored  and  synchronized  by  M. 

Therefore,  m  Figure  11,  only  those  actions  that  send  or  receive  messages  through  channels 
Cl  or  Cj  should  be  changed  by  the  procedure  described  in  Sections  2.1.  Other  I/O  events 
are  considered  internal  and  will  not  be  observed. 
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3  Implementation  and  Experimental  Results 

The  major  advantage  of  using  the  transformation  approach  is  to  use  protocol  validation 
tools  for  test  case  generation.  A  lot  of  efforts  can  be  saved  by  using  the  existing  programs. 
Since  the  transformation  described  in  this  paper  is  straightforward,  the  implementation 
is  nearly  trivial. 

To  demonstrate  the  idea,  a  protocol  validation  tool,  called  SPIN,  implemented  by 
Holzmann  at  AT&T  is  used  as  the  backbone  of  our  test  case  generator.  SPIN  uses  a  C- 
and  CSP-like  specification  language,  called  Promela,  to  specify  a  protocol.  The  program 
to  be  implemented  will  translate  a  specification  and  a  fault  model  wntten  in  Promela 
to  a  primary  P'  and  a  secondary  S',  and  construct  a  monitor  M.  The  program  contains 
around  1,000  lines  of  C++,  yacc,  and  lex  codes,  and  is  developed  by  a  single  person  within 
one  week.  On  a  SUN  SPARCstation,  the  program  took  less  than  20  seconds  to  generate 
the  following  test  ceise  for  the  specification  in  Figure  1  and  the  fault  model  in  Figure  2. 

uTSendd),  Rimsgd  ,0)  ,  u?Sendd)  ,  R!m»gd,l),  uTSendCl)  , 

R!m8g(l,2),  R?acJc(9),  u?Send(l),  R!m»g(l,3),  u?Send(l) 

The  meaning  of  the  test  case  is  as  follows: 

1.  Input  a  message  Send  from  channel  u.  The  content  of  the  message  is  1. 

2.  Expect  an  output,  msgCl  ,0) ,  at  channel  R,  with  message  1  and  sequence  number  0. 

3.  etc. 

If  constructing  fault  models  is  not  desirable,  a  program  that  randomly  modifies  the 
protocol  specification  to  create  fault  models  is  also  available.  The  program  has  the  fol¬ 
lowing  capabilities: 

1.  Randomly  modifying  the  value  of  a  constant  (c.g.,  changing  a  “4’  into  a  “5’ ). 

2.  Randomly  modifying  variable  references  (c.g.,  changing  a  variable  x  to  y). 

3.  Modifying  the  operations  in  an  expression  (c.g.,  changing  i  +  y  into  x  —  y). 

4.  Altering  the  control  flow  (e.g.,  inserting  goto  statement  arbitrarily). 

5.  Removing  a  statement. 

6.  Combination  of  the  above. 

The  fault  models  of  the  Go-Back-N  protocol  can  automatically  be  generated  by  the 
program  described  above.  The  fault  model  generator  can  then  be  integrated  with  the  test 
case  generator  to  find  test  cases  for  random  errors. 
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4  Performance  and  Complexity  Considerations 

In  order  not  to  confuse  with  the  states  in  an  EFSM,  we  define  a  system  state  that  is 
a  coUection  of  current  states  of  the  modules  and  current  values  of  the  variables.  For 
example,  if  the  sender  in  Figure  11  is  in  state  5i,  the  receiver  is  in  state  iZj,  the  network 
is  in  state  N^,  and  two  variables  i  and  y  in  the  protocol  specification  have  values  4  and 
5,  respectively,  the  current  system  state  of  the  protocol  will  be  (Si,  iZj,  iVs,  z  —  4,y  —  5). 

As  shown  in  Figure  3,  P',  S'  and  M  are  synchronized  by  the  messages  passed  among 
them.  For  example,  during  an  output  event,  P'  sends  a  message  to  M  and  stops  until  a 
resume  signal  is  received.  SimHarly,  M  sends  a  message  to  S'  and  cannot  move  until  an 
ok  signal  is  received.  Therefore,  automata  P',  5',  and  M  are  synchronized  at  the  point 
where  P  issues  an  output.  Between  two  input  or  output  actions,  P',  S'  and  M  can  run 
concurrently.  Since  M  does  not  have  any  transition  to  do  between  two  I/O  events,  the 
interleaving  is  between  P'  and  S'. 

Since  the  transitions  of  P'  and  S'  between  two  consecutive  I/O  events  are  independent, 
P'  and  S'  can  be  executed  atomically  and  still  yield  the  same  result  as  if  they  were  executed 
interleavingly.  That  is,  after  a  synchronized  I/O  event,  P'  can  run  first  until  its  next  I/O 
event,  and  then  S'  can  start  to  run  to  its  next  I/O  event.  Assuming  that  there  are  n 
system  states  in  the  protocol  specification,  and  m  system  states  in  the  fault  model,  the 
total  number  of  system  states  for  I  is  0[m  +  n),  instead  of  0(Tn.n).  Mostly,  m  and  n  are 
about  the  same,  and  the  complejcity  of  this  method  is  0{n). 

In  fact,  our  implementation  has  shown  good  performance,  in  spite  of  the  inefficiency  in 
using  SPIN  as  a  vahdation  tool.  To  validate  a  Promela  specification,  SPIN  first  generates 
a  C  program.  Compiling  and  running  the  program  will  generate  a  path  that  leads  to  an 
error.  The  path  is  retraced  by  SPIN  and  the  I/O  events  that  lead  to  the  deadlock  wiH 
be  recorded  by  M.  It  is  found  that  compiling  the  C  program  takes  most  of  the  execution 
time.  Therefore,  if  more  efficient  validation  tool  were  used,  the  performance  would  have 
been  even  better. 


5  Conclusion 

Protocol  validation  problem  has  been  studied  for  years  and  many  protocol  validation 
tools  are  available.  This  paper  proposes  a  method  to  transform  the  test  case  generation 
problem  to  a  protocol  validation  problem.  Therefore,  instead  of  developing  from  scratch, 
a  test  case  generator  can  be  built  upon  an  existing  protocol  validation  tool. 

The  transformation  method  takes  a  protocol  specification  and  a  fault  model  as  its 
input,  and  generates  three  automata,  namely  Primary  P',  Secondary  S',  and  a  Monitor  M. 
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The  system  containing  the  three  automata  is  treated  as  a  protocol  and  fed  into  a  protocol 
validation  tool.  A  deadlock  will  occur  if  there  is  a  discrepancy  between  the  protocol 
specification  and  its  fault  model.  By  analyzing  the  path  that  leads  to  the  deadlock,  and 
carefully  record  the  I/O  events,  a  test  case  can  be  found. 

The  method  does  not  introduce  extra  complexity  to  the  integrated  system  I.  The  total 
number  of  system  states  explored  by  the  protocol  validation  tool  is  in  about  the  same  order 
as  the  total  number  of  system  states  in  the  original  protocol  specification.  Therefore,  the 
state  explosion  problem  will  not  be  as  serious  as  a  general  protocol  vabdation  problem. 

The  method  was  implemented  in  a  very  short  period  of  time.  In  addition,  the  experi¬ 
ment  showed  that  the  performance  of  the  program  is  quite  acceptable;  a  test  case  can  be 
generated  within  a  minute.  Therefore,  those  who  have  a  protocol  validation  tool  may  now 
use  this  method  to  transform  the  validation  tool  into  a  test  case  generator  with  virtually 
no  extra  cost. 
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Abstract 

A  method  is  proposed  to  transform  test  case  generation  problem  to  protocol  validation 
problem.  Protocol  validation  has  been  studied  for  years  and  many  validation  tools  are 
available.  By  transforming  a  test  case  generation  problem  into  a  protocol  validation 
problem,  a  protocol  validation  tool  can  be  used  to  generate  test  cases.  The  method 
can  be  implemented  in  a  very  short  period  of  time.  The  complexity  of  the  proposed 
method  in  searching  for  a  test  case  is  £}(n),  where  n  is  the  number  of  system  states  In  the 
specification. 


1  Introduction 

Test  case  generation  (TCG)  for  Finite  State  Machines  (FSM)  has  been  studied  for  years, 
and  fruitful  results  have  been  produced  [1,  2,  3,  4|.  The  FSM  is  a  simple  model  that 
ignores  the  data  flow  of  a  protocol  and  concentrates  on  the  protocol’s  control  flow.  In 
other  words,  it  simplifies  a  protocol  into  a  state-transition  machine.  However,  ignoring 
the  data  flow  of  the  protocol  often  removes  many  interesting  properties  from  the  protocol. 
As  an  example,  it  is  hard  to  specify  a  simple  protocol  like  Go-Back-N  in  FSM  without 
losing  those  important  properties  associated  with  the  protocol’s  window  size. 

Therefore,  most  protocol  specifications  are  written  in  more  sophisticated  models  such 
as  Extended  Finite  State  Machine  (EFSM)  [5],  Estelle  [6],  LOTOS  [7],  or  other  program¬ 
ming  languages.  These  models  are  called  extended  models  in  this  paper  with  respect  to 
the  basic  FSM  model.  To  be  more  practical,  a  test  case  generation  method  must  be  able 
to  generate  test  cases  from  extended  models.  However,  the  difficulty  is  that  to  test  an 
extended  model,  one  needs  to  test  not  only  the  control  flow,  but  also  the  data  flow  of  the 
protocol.  Testing  both  control  and  data  flows  is  considered  a  challenging  problem  and 

•Research  reported  herein  was  supported  bjr  U.S.  Army  Research  Office,  under  contracts  No.  DAAL03- 
91-G-0093  and  No.  DAAL03-92-G-0184.  The  views,  opinions,  and/or  findings  contained  in  this  paper  are 
those  of  the  authors  and  should  not  be  construed  as  an  official  Department  of  the  Army  position  policy 
or  decision. 
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not  much  work  has  been  done  so  far.  Some  references  about  the  test  case  generation  for 
the  extended  models  can  be  found  in  [8,  9,  10,  11,  12,  13,  14]. 

A  test  case  can  be  used  for  detecting  a  certain  type  of  faults,  which  are  called  the  fault 
models  of  the  test  case  [15].  Because  of  the  complexity  involved  in  searching  test  cases 
for  extended  models,  it  is  believed  that  fault  models  should  be  used  as  a  guide  to  simplify 
the  search  [16,  17].  Traditionally,  a  TCG  method  is  dedicated  to  generating  test  cases  for 
certain  fixed  fault  models.  On  the  contrary,  a  TCG  method  based  on  fault  models  takes 
both  a  protocol  specification  and  a  given  fault  model  as  input  and  generates  a  test  case 
for  the  fault  model.  An  I/O  sequence  can  be  used  as  a  t^t  case  if  the  specification  and 
the  fault  model  behave  differently  when  appl3nng  the  I/O  sequence. 

A  fault  model  is  usually  a  modification  of  the  original  protocol  specification,  and  can 
be  described  by  the  same  model  used  to  define  the  protocol  specification.  For  example, 
Figure  1  is  the  sender  of  a  Go-Back-N  protocol  specified  in  EFSM  with  a  window  size 
equal  to  four  (W^=4).  A  fault  model  like  the  one  drawn  in  Figure  2  has  a  window  size 
being  set  to  five.  Note  that  only  the  action  cissociated  with  the  first  transition  is  changed^ 

Generating  test  cases  based  on  a  given  fault  model  has  the  following  advantages: 

1.  Every  test  case  has  a  well  defined  test  purpose.  That  is,  the  types  of  errors  a  test 
case  can  detect  is  automatically  provided.  In  addition,  those  who  test  a  protocol 
implementation  with  the  test  case  will  have  the  confidence  that  the  fault  described 
by  the  fault  model  does  not  exist  in  the  implementation. 

2.  It  reduces  the  complexity  of  finding  a  test  case.  Instead  of  searching  aimlessly,  a 
TCG  method  can  use  a  given  fault  model  as  a  goal  to  direct  the  search. 

3.  Users  can  chose  to  test  critical  faults  first,  and  test  minor  errors  later. 

4.  It  is  more  flexible  than  the  traditional  methods.  The  traditional  TCG  methods  have 
fixed  fault  models  embedded  in  them.  If  a  critical  fault  does  not  contain  in  the  fault 
models,  the  traditional  TCG  methods  cannot  effectively  test  this  fault. 

^Thc  EFSMi  used  in  this  paper  have  fire  types  of  actions  associated  with  their  transitions. 

1.  Assignment:  W  :=r  4  assigns  value  4  to  variable  W. 

2.  Input:  RlAck{A)  receives  message  Ack  whose  argument  is  assigned  to  variable  A. 

3.  Output:  RIM 5y(B[5m],  Sm)  sends  a  message  Msg  with  arguments  B[5m]  and  5m,  where  5[Sm] 
is  the  5m^th  clement  in  array  3. 

4.  Condition:  A  transition  with  action  k  <>  5m  can  only  be  executed  when  k  and  5m  are  not  equal. 

5.  Timeout  (T/0):  The  transition  wifl  be  executed  after  a  certain  amount  of  time  expires. 
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R7Ack(A) 


Figure  1:  Go-Back-N  protocol  specified  in  EFSM 


Figure  2:  A  fault  model  of  Figure  1  (The  rest  of  this  figure  is  the  same  as 


Figure  1 
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In  this  paper,  the  problem  of  TCG  based  on  fault  models  is  transformed  into  a  protocol 
validation  (PV)  problem.  Protocol  validation,  which  is  used  to  detect  design  errors  in  a 
protocol  specification,  has  been  studied  for  years.  While  many  protocol  validation  tools 
have  been  made  available,  automatic  test  case  generators  are  still  hard  to  find.  Therefore, 
a  method  is  proposed  to  transform  TCG  to  PV  so  that  available  validation  tools  can  be 
used  to  generate  test  cases.  It  will  also  be  shown  later  that  the  transformation  method 
not  only  can  be  used  to  generate  test  cases  for  weak  conformance,  but  also  can  be  used 
to  generate  test  cases  for  strong  conformance,  functional  testing,  and  multiple-module 
specifications. 

It  is  well  known  that  there  is  a  so  called  state,  explosion  problem  for  protocol  validation, 
which  means  that  the  number  of  states  generated  by  a  protocol  validation  tool  increases 
exponentially  when  the  protocol  specification  becomes  more  complicated.  The  method 
proposed  in  this  paper  takes  a  protocol  specification  and  a  fault  model  as  its  input  and 
generates  a  combined  system  to  be  fed  into  a  protocol  validation  tool.  It  is  also  shown 
in  this  paper  that  the  complexity  of  the  combined  system  is  0{n)  if  the  number  of  global 
states  in  the  original  protocol  specification  is  n.  Therefore,  the  state  explosion  problem 
wiU  not  occur  as  long  as  it  will  not  occur  in  the  original  specification. 

The  organization  of  this  paper  is  as  follows.  In  Section  2,  the  transformation  from  the 
test  case  generation  problem  to  the  protocol  validation  problem  is  proposed.  The  same 
section  also  discusses  how  the  transformation  to  weak  and  strong  conformance,  functional 
testing,  and  multiple-module  protocols  can  be  applied.  In  Section  3,  the  implementation  of 
the  test  case  generator  is  introduced,  and  some  experimental  results  are  discussed.  Finally, 
the  complexity  of  the  test  case  generator  is  discussed  in  Section  4  and  a  conclusion  is  given 
in  Section  5. 

2  Transforming  TCG  to  PV 

2.1  The  Transformation 

A  test  case  for  a  fault  model  is  an  I/O  sequence  that  detects  the  discrepancies  between 
the  fault  model  and  the  protocol  specification.  That  is,  the  test  case  is  a  possible  I/O 
sequence  for  one,  but  not  for  the  other.  For  example,  an  I/O  sequence  can  be  used  as  a 
test  case  if  it  can  be  generated  from  the  protocol  specification,  but  cannot  be  reproduced 
from  the  fault  model.  In  other  words,  if  a  protocol  implementation  contains  an  error 
described  by  the  fault  model,  applying  the  input  sequence  of  the  test  case  to  the  imple¬ 
mentation  will  produce  an  unexpected  output  because  the  I/O  sequence  cannot  appear 
in  the  implementation. 

The  task  is  to  find  an  I/O  sequence  that  can  only  be  applied  to  either  the  protocol 
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specification  or  the  fault  model,  but  not  both.  Let  P  (for  Primary)  be  an  automaton  that 
describes  either  the  protocol  specification  or  the  fault  model,  and  let  S  (for  Secondary)  be 
an  automaton  that  describes  the  other.  If  P  and  S  are  executed  synchronously,  whenever 
P  makes  a  certain  output,  5  must  make  the  same  output;  otherwise,  it  will  be  a  discrep¬ 
ancy.  Similarly,  if  P  requires  a  certain  input,  5  must  wait  for  the  same  input;  otherwise, 
it  will  be  a  discrepancy  as  well. 

The  idea  here  is  to  construct  a  system  that  will  deadlock  when  P  and  S  take  different 
input  or  output  actions.  The  combined  system  can  be  fed  into  a  protocol  validation  tool. 
When  the  validation  tool  signals  a  deadlock  error,  one  can  trace  through  the  execution 
path  that  causes  the  deadlock.  Then,  the  I/O  events  generated  by  the  path  can  be  used 
as  a  test  case. 

The  first  step  is  to  modify  automaton  P.  Let  P'  be  an  automaton  the  same  as  P, 
except  for  the  following  differences: 

1.  For  every  output  action  in  P,  make  the  same  output.  Then,  wait  for  a  resume 
signal. 

2.  For  every  input  action  in  P,  output  a  message  that  requests  the  input  first.  Then, 
wait  for  the  input. 

3.  For  every  timeout  in  P,  output  a  message  labeled  T/0.  Then  wait  for  a  resume 
signal. 

Next,  make  an  automaton  5'  similar  to  5  except  for  the  following  changes: 

1.  For  every  output  action  in  5,  input  a  message  first.  If  the  input  message  is  the  same 
as  the  message  to  be  output,  output  an  ok  signal. 

2.  For  every  input  action  in  5,  input  the  message.  Then,  output  an  ok  signal. 

3.  Remove  every  timeout  in  5. 

Finally,  let  M  (for  Monitor)  be  an  automaton  communicating  with  P*  and  5'.  M 
provides  a  variable  for  each  parameter  of  every  input  action  in  P'.  The  variables  are 
initialized  to  their  lower  bound  values.  Monitor  M  performs  the  following: 

1.  Increment  the  value  of  a  variable  by  one  nondeterministically,  unless  an  upper  bound 
is  reached. 

2.  When  an  output  from  P'  is  received,  pass  the  message  to  5'  and  wait  for  an  ok 
signal  from  5'.  After  receiving  the  ok  signal,  send  a  resume  signal  to  P',  and  record 
the  output  event. 
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Table  1:  Modification  made  by  P\  S\  and  M 


Output 

Original 

GlTnsg(x\i  •  •  * ,  *«) 

Primary  P* 

M!T7Wg(xi,  •  *  •  ,  Xn) 
Mlresume 

Secondary  S' 
M?TTWg(pi,“*,Pn) 

Fl  =  Xi 

Pn  —  Xn 

M\ok 

Monitor  M  1 

P'?msg{pi,---,Pn} 

5'!injff(pi,--,Pn) 

S"!ok 

P^lresume 

Input 

G?Tn4g(xi,  *  •  • ,  XnJ  | 

M\Teque3i{Tnsg) 
M?T7U^^(xt,  ‘  ‘  1  Xn) 

M?TMg(xi,  -  •  ■  ,Xn) 

Mlok 

P'lTequestljnsg) 

5Mmjg(xi,---,Xn) 

S' 7  ok 

P'lmjg(xi,'--,Xn) 

Timeout 

TIO 

M'.TIO 

MTrefume 

P'lTjO 

P’Wtaumjt 

3.  When  P'  asks  for  an  input  message,  send  the  message  to  S'  first.  After  receiving  a. 
ok  from  S',  send  the  same  message  to  P'  and  record  the  input  event. 

4.  When  P'  outputs  a  T/0  message,  send  resume  signals  to  P',  and  record  the  timeou 
event. 

The  above  modification  is  summarized  in  Table  1.  Let  I  (for  Integrated)  be  an  inte 
grated  system  that  contains  P',  S',  and  M.  Then,  I  will  deadlock  if  P  generates  some 
I/O  sequences  that  cannot  be  reproduced  by  S.  This  can  be  briefly  proved  as  Mows. 

1.  If  S  cannot  generate  the  same  message  output  by  P,  S'  wiD  stop.  Without  receiv 
ing  any  ok  signal,  M  will  be  blocked  and  wiU  not  send  the  resume  signal  to  P 
Therefore,  P'  will  be  blocked  as  well. 

2  H  S  ,-ai  not  rccivo  tho  t»t.  input  at  P  doot.  S'  wiU  bn  blocked  «ld  no  ok  tigntd 
WiU  bn  send.  Thnrnforn,  M  wiU  bn  blocked  and  P'  wffl  never  receive  the  r.tnine 
signal.  The  system  deadlocks. 

The  protocol  among  M,  P'  and  S'  is  illustrated  in  Figure  3.  When  P'  sends  a  message 
msg  to  M,  M  passes  it  to  S'.  If  the  osg  is  also  a  message  that  S'  intends  to  output,  S 
WiU  send  an  ok.  Upon  receiving  the  ok  signal,  M  sends  a  resume  to  P'  (Figure  3a)  On 
the  other  hand,  if  P'  needs  to  receive  a  certain  message,  it  sends  a  request  to  M.  Upon 
receiving  the  request,  M  sends  the  message  to  S'  first.  If  an  ok  is  received,  M  sends  the 
requested  message  to  P'  (Figure  3b).  The  timeout  message  between  P'  and  M  are  used 
to  record  the  timeout  event,  and  wiU  not  affect  the  overaU  execution  of  the  system. 

An  example  of  the  transformation  is  shown  in  Figures  4  to  6.  Figure  4  is  the  primary 
automaton  P'  modified  from  the  Go-Back-N  protocol  specification  in  Figure  1.  The 
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(a)  Output 


t 

(b)  Input 


Figure  3:  Communication  among  M,  P'  and  S’ 

,h.dcd  arrows  aad  circle  are  Ike  transitions  and  state,  keinj  chanjed  ““'^”8 
mle.  deseriked  in  Table  1.  Fijure  5  is  the  seeondary  ..tomato.  S  moWed  tmm  the 
fault  model  shown  in  Flsure  2.  Monitor  M  tor  Fijures  4  and  5  .s  drawn  m  Figure  6^  Nole 
that  aU  the  I/O  events  in  P’  and  S'  are  changed  into  communication  between  P  and  M, 

and  between  S'  and  M,  respectively. 

When  a  protocol  speciUcation  and  its  fault  models  ...  spedliml  by  a  formal  model 
(such  as  FSM,  EFSM,  EsteUe.  LOTOS,  SDL.  Petri-Net,  Promda,  etc.),  .t  is  tnvid  to 
transform  P  and  S  into  F  mid  S',  respectivdy.  It  is  also  straightforward  to  construe 
the  monitor  M.  Automat.  P\  S'  Kid  M  can  be  ted  into  a  validation  tool  for  the  formal 
model  and  a  deadlock  CKS  be  found  if  there  is  an  I/O  sequence  that  is  possible  for  P  bu 
cannot  be  generated  by  S.  By  retracing  the  path  leading  to  the  deadlock,  monito,  M  wiU 
record  the  I/O  events  along  the  path.  The  recorded  I/O  event  smiuence  can  then  be  used 

as  a  test  case. 


2.2  Weak  and  Strong  Conformance 

There  are  two  types  of  conformance  between  a  protocol  specification  and  its  implemen¬ 
tation.  The  weak  conformance  indicates  that  a  protocol  implementation  should  perform 
every  function  defined  in  its  specification.  In  other  words,  things  that  ought  to  happen 
should  happen.  The  strong  con/omance  imposes  an  additional  constrain  which  s  ates 
that  a  protocol  implementation  cannot  have  any  behavior  not  defined  by  the  protocol 
specification.  That  is,  tHngs  that  cannot  happen  must  not  occur. 

A  fault  model  violating  the  weak  conformance  cannot  perform  some  functions  defined 
by  the  protocol  specification.  In  other  words,  there  exists  an  I/O  event  sequence  that 
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Xt-MlB(A) 


can  be  generated  by  the  specification,  but  cannot  happen  m  the  fault  model.  To  generate 
a  test  Le  for  the  fault  model,  one  can  use  the  protocol  specification  as  the  pnmary 
automaton  P,  use  the  fault  model  as  the  secondary  automaton  5,  apply  the  transformation 
in  Section  2.1,  and  feed  the  resulting  system  I  into  a  protocol  validation  tool. 


A  fault  model  that  violates  the  strong  conformance  has  some  execution  paths  that  are 
not  specified  in  the  protocol  specification.  That  is,  some  I/O  sequence  generated  by  the 
fault  model  can  never  happen  in  the  specification.  Thus,  if  one  use  the  fault  model  as 
the  primary  automaton  P  and  use  the  specification  as  the  secondary  automaton  5,  one 
can  find  a  test  case  with  the  method  described  in  Section  2.1.  When  the  input  of  the 
test  case  is  appUed  to  a  protocol  implementation,  and  an  expected  output  appears,  the 
implementation  must  contain  an  error  described  by  the  fault  model. 

It  is  possible  that  a  fault  model  violates  both  weak  and  strong  conformance.  In  this 
case,  treating  the  protocol  specification  as  either  the  primary  or  the  secondary  wiU  work. 
Sometimes,  however,  it  is  difficult  to  tell  whether  a  fault  model  violates  the  weak  or  strong 
conformance.  In  such  a  case,  if  one  method  cannot  find  a  test  case,  the  other  must  be 

tried. 


2.3  Functional  Testing 


It  is  useful  to  create  test  cases  that  ensure  the  correctness  of  certain  behavior  in  the 
protocol  specification.  Such  “behavior”  is  often  called  a  Action  or  a  requirement  o{  the 
protocol  specification.  For  example,  a  requirement  of  the  Go-Back-N  protocol  m  Figure  1 
can  be  “there  are  no  more  than  three  messages  in  the  channel  at  any  given  time” 

In  order  to  test  if  a  protocol  implementation  conforms  with  the  requirement,  a  fault 
model  that  violates  the  requirement  is  constructed.  However,  since  a  requirement  usuaUy 
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,  portion  Of  .ho  ort,inU  p,o.o.I 

to  cotislmc.  a  lault  model  from  the  enliie  oecessaty  to  violate  the  lequiiemeat. 

C.„  be  created  by  inclading  on  y  the  above  paragraph 

Fo,  example,  a  fault  ‘  5  Hor,  is  no  restriction  on  how 

LlJ^nrbfstm  :  I^rieceiver  cnsecutively  before  the  sender  recerves  an 

acknowledgment . 


moA  w 


Figure  7.  A  fault  model  that  sends  more  than  three  messages  at  a  time. 

M,  a  sij..  “  rr;: ttS:: :  tz 

model  only  specifies  parti  *  ^  ^  g  modification  of  the  transformation 

specification  may  not  exist  m  the  fault  modd.  Hence, 

described  in  Section  2.1  should  be  noted  as  follows. 

•  To  change  P  {S)  into  P'  (5 )'. 

*  ♦  ms-tion  exists  in  both  P  and  S,  Mow  the  procedure  in 

1.  If  an  input  or  output  action  exists  in  oovu 

Section  2.1.  ,  .  ir  j 

*1.  ♦  »«et<  onlv  in  P  (SI,  send  the  output  to  M  and 

2.  For  every  output  message  that  exists  only  in  r  j, 

wait  for  a  rasuiio  signal  from  M. 

fhaf  exists  only  in  P  (5),  send  an  request  for  the 

3.  For  every  input  message  that  Y 

iuput  to  M  and  wait  tor  the  inp.1  event  from  M. 

•  To  construct  M: 

1.  For  those  input  or  output  action,  that  exist  in  both  F  and  S,  Mow  the  pro- 
cedure  in  Section  2.1. 

iiaat  exists  only  in  P  (5)  is  received  from  P  (5  ),  record 

2.  If  an  output  message  that  exists  o  y  , 

the  output  event  and  send  a  resmi.  signal  to  P  (5  ). 

/  •  F  ilt.t  exists  only  in  P  (S)  «  received  from  P'  (S'),  record 

3.  If  a  request  for  mput  that  exists  omy  m  \  > 

the  input  event  and  send  the  input  message  to  P  [b  )- 


1  •  P  or  S  the  monitor  M  will 

I„  other  word,,  it  „  iop».  or  outpot  metsase  orosts  ^  .k.  ,/0  event 

„„t  try  to  .yaehronire  P'  .»d  S'  ‘he  menage  It  w,U  op  y 

and  release  the  automaton  that  generates  t  e  even  .  or  ex  ^^jjed  according  to  the 
“ntursend^  exists  only  in  Figures  S,  and 

.hove  procedure.  The  resultmg  EFSM  .  1  ,kow  the 

10,  respectively.  Note  that  tne  sna  Section  2.1. 

di  jerence  between  the  method  in  this  sectton  and  the  one 


Figure  8:  The  primary  P'  from  the  fault  model  in  Figure  7 


Figure  9:  The  secondary 


S'  from  the  specification  in  Figure  1. 
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Figure  10:  The  monitor  M  from  the  fault  model  in  Figure  7  and  the  specification  in 
Figure  1. 

2.4  Test  Case  Generation  for  Multiple  Modules 

Test  cases  can  also  be  generated  for  multiple  modules  using  this  method.  For  example, 
one  may  want  to  test  how  a  protocol  containing  a  sender  and  a  receiver  operates  when 
connected  with  a  network.  The  whole  system  can  be  modeled  liV**  the  one  in  Figure  11. 


Figure  11:  A  multiple-module  specification 
A  modification  should  be  made  when  testing  a  multiple-module  specification: 

•  Only  those  I/O  actions  that  are  used  to  communicate  with  the  outside  world  should 
be  monitored  and  synchronized  by  M . 

Therefore,  in  Figure  11,  only  those  actions  that  send  or  receive  messages  through  channels 
C\  or  Cj  should  be  changed  by  the  procedure  described  in  Sections  2.1.  Other  I/O  events 
are  considered  internal  and  will  not  be  observed. 
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3  Implementation  and  Experimental  Results 

The  major  advantage  of  using  the  transformation  approach  is  to  use  protocol  validation 
tools  for  test  case  generation.  A  lot  of  efforts  can  be  saved  by  using  the  existing  programs. 
Since  the  transformation  described  in  this  paper  is  straightforward,  the  implementation 
is  nearly  trivial. 

To  demonstrate  the  idea,  a  protocol  validation  tool,  called  SPIN,  implemented  by 
Hoixmann  at  AT&T  is  used  as  the  backbone  of  out  test  case  generator.  SPIN  uses  a  C- 
and  CSP-like  specification  language,  called  Promela,  to  specify  a  protocol.  The  program 
to  be  implemented  will  translate  a  specification  and  a  fault  model  written  in  Promela 
to  a  primary  P'  and  a  secondary  S',  and  construct  a  monitor  M.  The  program  contains 
around  1,000  lines  of  C++,  yacc,  and  lex  codes,  and  is  developed  by  a  single  person  within 
one  week.  On  a  SUN  SPARCstation,  the  program  took  less  than  20  seconds  to  generate 
the  following  test  case  for  the  specification  in  Figure  1  and  the  fault  model  in  Figure  2. 

uTSendd),  Rlmsgd.O).  u’Sendd)  ,  R!n»gd,l),  uTSendd)  , 

R!m8gd,2),  R?aclt(9),  uTSendd),  R!m8gd,3),  uTSendd) 

The  meaning  of  the  test  case  is  as  follows: 

1.  Input  a  message  Send  from  channel  u.  The  content  of  the  message  is  1. 

2.  Elxpect  an  output,  msg(l  ,0),  at  channel  R,  with  message  1  and  sequence  number  0. 

3.  etc. 

If  constructing  fault  models  is  not  desirable,  a  program  that  randomly  modifies  the 
protocol  specification  to  create  fault  models  is  also  available.  The  program  has  the  fol¬ 
lowing  capabilities: 

1.  Randomly  modifying  the  value  of  a  constant  (e.g.,  changing  a  “4  into  a  ‘5  ). 

2.  Randomly  modifying  variable  references  (e.g.,  changing  a  vanable  i  to  y). 

3.  Modifying  the  operations  in  an  expression  (e.g.,  changing  z  +  y  into  x  —  y). 

4.  Altering  the  control  flow  (e.g.,  inserting  goto  statement  arbitrarily). 

5.  Removing  a  statement. 

6.  Combination  of  the  above. 

The  fault  models  of  the  Go-Back-N  protocol  can  automatically  be  generated  by  the 
program  described  above.  The  fault  model  generator  can  then  be  integrated  with  the  test 
case  generator  to  find  test  cases  for  random  errors. 
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4  Performance  and  Complexity  Considerations 

In  order  not  to  confuse  with  the  states  in  an  EFSM,  we  define  a  system  state  that  is 
a  coUection  of  current  states  of  the  modules  and  current  values  of  the  variables.  For 
example,  if  the  sender  in  Figure  11  is  in  state  Si,  the  receiver  is  in  state  Ri,  the  network 
is  in  state  Ns,  and  two  variables  x  and  y  in  the  protocol  specification  have  values  4^and 
5,  respectively,  the  current  system  state  of  the  protocol  will  be  {Si,R2,N3,x  —  4,y  —  5). 

As  shown  in  Figure  3,  P',  S'  and  M  are  synchronized  by  the  messages  passed  among 
them.  For  example,  during  an  output  event,  P'  sends  a  message  to  M  and  stops  until  a 
resua#  signal  is  received.  Similarly,  M  sends  a  message  to  5'  and  cannot  move  until  an 
ok  signal  is  received.  Therefore,  automata  F,  S',  and  M  are  synchronized  at  the  point 
where  P  issues  an  output.  Between  two  input  or  output  actions,  P' ,  S'  and  M  can  run 
concurrently.  Since  M  does  not  have  any  transition  to  do  between  two  I/O  events,  the 

interleaving  is  between  P*  and  5'. 

Since  the  transitions  of  P'  and  S'  between  two  consecutive  1/ 0  events  are  independent, 
F  and  S'  can  be  executed  atomically  and  stiU  yield  the  same  result  as  if  they  were  executed 
interleavingly.  That  is,  after  a  synchronized  I/O  event,  F  can  run  first  untd  its  next  I/O 
event,  and  then  S'  can  start  to  run  to  its  next  I/O  event.  Assuming  that  there  are  n 
system  states  in  the  protocol  specification,  and  m  system  states  in  the  fault  model,  the 
total  number  of  system  states  for  I  is  0{m  +  n),  instead  of  0(mn).  Mostly,  m  and  n  are 
about  the  same,  and  the  complexity  of  this  method  is  0{n). 

In  fact,  our  implementation  has  shown  good  performance,  in  spite  of  the  inefficiency  in 
using  SPIN  as  a  vahdation  tool.  To  validate  a  Promela  specification,  SPIN  first  generates 
a  C  program.  Compiling  and  running  the  program  will  generate  a  path  that  leads  to  an 
error.  The  path  is  retraced  by  SPIN  and  the  I/O  events  that  lead  to  the  deadlock  wiU 
be  recorded  by  M.  It  is  found  that  compiling  the  C  program  takes  most  of  the  execution 
time.  Therefore,  if  more  efficient  vahdation  tool  were  used,  the  performance  would  have 
been  even  better. 


5  Conclusion 

Protocol  validation  problem  has  been  studied  for  years  and  many  protocol  validation 
tools  are  available.  This  paper  proposes  a  method  to  transform  the  test  case  generation 
problem  to  a  protocol  validation  problem.  Therefore,  instead  of  developing  from  scratch, 
a  test  case  generator  can  be  built  upon  an  existing  protocol  validation  tool. 

The  transformation  method  takes  a  protocol  specification  and  a  fault  model  as  its 
input,  and  generates  three  automata,  namely  Primary  F,  Secondary  S',  and  a  Monitor  M. 
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The  system  containing  the  three  automata  is  treated  as  a  protocol  and  fed  into  a  protocol 
validation  tool.  A  deadlock  will  occur  if  there  is  a  discrepancy  between  the  protocol 
specification  and  its  fault  model.  By  analyzing  the  path  that  leads  to  the  deadlock,  and 
carefully  record  the  I/O  events,  a  test  case  can  be  found. 

The  method  does  not  introduce  extra  complexity  to  the  integrated  system  I.  The  total 
number  of  system  states  explored  by  the  protocol  vahdation  tool  is  in  about  the  same  order 
as  the  total  number  of  system  states  in  the  original  protocol  specification.  Therefore,  the 
state  explosion  problem  will  not  be  as  serious  as  a  general  protocol  validation  problem. 

The  method  was  implemented  in  a  very  short  period  of  time.  In  addition,  the  experi¬ 
ment  showed  that  the  performance  of  the  program  is  quite  acceptable;  a  test  case  can  be 
generated  within  a  minute.  Therefore,  those  who  have  a  protocol  validation  tool  may  now 
use  this  method  to  transform  the  validation  tool  into  a  test  case  generator  with  virtually 
no  extra  cost. 
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